Meson: 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)): https://github.com/mesonbuild/meson/issues/3304#issuecomment-407704983

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"