ninja backend + Visual Studio uses wrong name_prefix + extension for libraries by default

[madebr]

Describe the bug
When building libraries using MSVC and the ninja backend, a lib name_prefix is added.
By default, the name_prefix for MSVC should be "" (the empty string).

Also, the static libraries have the .a extension, where it should be .lib.

To Reproduce

meson.build

project('example',
    ['c'],
    default_options : ['default_library=static']
)

library('mylibrary',
    ['mysource.c']
)

mysource.c

int my_function(void) {
    return 1337;
}

Expected behavior
A mylibrary.lib file is built.

Actual behavior
A libmylibrary.a file is built.

system parameters

• cross build? no
• os: Windows 10
• compiler: Visual Studio 2017
• python version? 3.8.3
• meson version? 0.54.2
• ninja version? 1.9.0

[dcbaker]

Using .a is an explicit design choice. There is no real requirement on what a static library extension needs to be on windows, and we picked .a to differentiate from the interface libraries needed to link against .dlls (which IIRC must be .lib), which is a requirement to be able to build and install both a static and shared library at the same time.

[dcbaker]

I can't remember why (or if we should) use lib as a prefix, that does seem off to me.

[madebr]

It's a weird default for the suffix when using MSVC. It's not expected.
This means that the filename depends on the backend, because the msvc* backends do not do this.
Also, a lot of tools assume .lib extensions (e.g. cmake/conan), when looking for libraries.

[TheQwertiest]

Using .a is an explicit design choice. There is no real requirement on what a static library extension needs to be on windows

And it is a wrong and a bad design choice. There are no hard requirements, no. But! As it was mentioned above not a single IDE or a build-system expects static libraries to have a *.a extension. Even meson itself uses name*.lib patter to search for static libraries! This behavior violates long established practices on Windows.

I understand, that the ship have sailed and the default behaviour can't be (easily) changed. But, IMO, it should be made possible for the user to make static libraries to generate expected output with a single cmd switch and without having to rename libs manually in the install script.

Generating both libraries is not really common on Windows, but it's usually solved by adding various (alas, horrible) suffixes to the produced output, e.g. boost-system-vc140-s-gd.lib vs boost-system-vc140-gd.lib.

In other words priorities were mixed up when this design was made: it made common scenario harder to use, and simplified(?) an uncommon scenario.

[TheQwertiest]

@dcbaker , backend:ninja tag is not needed here, since this problem is present on all backends.

[TheQwertiest]

And it's often not possible to use both_libraries on windows anyway, because of the different defines that are required for shared and static libraries (most prominent example is __declspec(export)): #3304 (comment)

Which renders the reason behind this naming scheme kinda moot: "this naming scheme is required for both_libraries to work, which actually doesn't work properly in a lot of common scenarios on Windows"

[SpaceIm]

What is the status of this issue? It's quite tedious to manually rename static libs after installation.

[eli-schwartz]

Even meson itself uses name*.lib patter to search for static libraries!

Sure, Meson searches for .lib, and also for non-MSVC compilers, i.e. mingw GCC, it also searches for dll.a. This goes together, not only with the fact that Meson creates .dll.a, but the fact that the ecosystem also creates .dll.a.

There's a relevant comment in the implementation that describes why we do this.

I can't remember why (or if we should) use lib as a prefix, that does seem off to me.

@dcbaker, this is also answered by the comment, I think.

Anyway:

meson/mesonbuild/build.py

Lines 1976 to 1982 in d141b85

	# By default a static library is named libfoo.a even on Windows because
	# MSVC does not have a consistent convention for what static libraries
	# are called. The MSVC CRT uses libfoo.lib syntax but nothing else uses
	# it and GCC only looks for static libraries called foo.lib and
	# libfoo.a. However, we cannot use foo.lib because that's the same as
	# the import library. Using libfoo.a is ok because people using MSVC
	# always pass the library filename while linking anyway.

This seems pretty relevant. Not only do we use mingw's upstream-preferred file extension, but we also use mingw's preferred file prefix.

This behavior violates long established practices on Windows.

I love this thought of Windows having long established practices. :)

Since MSVC apparently does require you to pass the filename anyway, and doesn't care what you call it, while the extension we do use is the one that mingw expects and insists on... it's not clear to me that this is something which should change.

At least, using "lib" has to go together with using ".a", or we sharply regress for mingw.

Could we use foo.lib instead of libfoo.a? The logic here seems to be that we can, as long as people don't build both shared and static. But if they do, then what? Should we error out saying that "no, you cannot do that, lots of projects don't support both at the same time so we will simply refuse altogether to allow you to even try it"?

[eli-schwartz]

If cmake and conan don't look for the filenames that are traditionally used on mingw regardless of build system (and which I believe autotools uses in addition to Meson) that seems like something that might be worth fixing independent of any resolution here.