Add option to change the library naming scheme

[jpakkane]

With this you can choose the library naming scheme regardless of the platform used.

A thing to decide before merging is whether we should keep the current scheme (.a on Windows) or switch to the platform default (.dll for libs and .dll.lib for import libs).

[eli-schwartz]

A thing to decide before merging is whether we should keep the current scheme (.a on Windows) or switch to the platform default (.dll for libs and .dll.lib for import libs).

This isn't the platform default at all, though? We're just making up our own new convention that nobody uses, aren't we? Isn't it .lib alone.

As far as I can tell this entire feature despite being cross platform basically exists solely to cater to windows users specifically. It should be a fatal error to set this property on Linux (or at least to change it from the default).

The purpose of setting it is really just to make users happy who insist that .a should mean mingw-gcc+ucrt while .lib should mean MSVC+ucrt. I'm not necessarily averse to making those users happy but it feels like a leaky abstraction if it affects other platforms too.

Making this change by default seems like it would break existing users who rely on the mingw linker search pattern support for detecting libraries by name rather than filepath (and which currently supports both lib*.a and *.lib, doesn't it?)

[jpakkane]

This isn't the platform default at all, though? We're just making up our own new convention that nobody uses, aren't we? Isn't it .lib alone.

This just copies the way rustc does it. Which is the most reasonable way of making it work in a cross platform way.

[jpakkane]

As far as I can tell this entire feature despite being cross platform basically exists solely to cater to windows users specifically.

Actually no, for example on macOS you might want to use .so instead of .dylib sometimes.

[jpakkane]

Now tests pass, the clang ones are the same as in master. Questions still to answer:

• Do we need a "cygwin" value or is "unix" the same?
• Should there be a "legacy" value that does exactly the same as before with "default" being a shorthand for "the new scheme for the current platform"
• Would we need a "100% pure Windows" with clashing .lib names (which has its own set of problems) or is the current approach good enough?

[bonzini]

Do we need a "cygwin" value or is "unix" the same?

Doesn't cygwin install libraries with cyg as the prefix? Also, iOS is different from macOS in that it only uses -dynamiclib; I am not sure if that means that shared_module uses .dylib on iOS, and that there should be different naming conventions, because I am not sure what's the rationale for this feature.

Is there an issue here on GitHub describing the problem you're trying to solve? The documentation is extremely scant in both the what and the why departments.

Would we need a "100% pure Windows" with clashing .lib names (which has its own set of problems) or is the current approach good enough?

Maybe if you forbid both_libraries or default_library=both. But again, difficult to answer without knowing why you need this in the first place.

[eli-schwartz]

As far as I can tell this entire feature despite being cross platform basically exists solely to cater to windows users specifically.

Actually no, for example on macOS you might want to use .so instead of .dylib sometimes.

I'll take your word for it. In that case it is still a logical error to set this option on a Linux host machine, and I believe we must reflect that by making it a setup-time fatal error to attempt to set it in that configuration.

... I am nonetheless surprised to hear that macOS users need to select this at setup time. I could hear an application itself being picky, but in that case I'd expect them to set name_suffix directly and not let end users set the "wrong" values.

[jpakkane]

Is there an issue here on GitHub describing the problem you're trying to solve? The documentation is extremely scant in both the what and the why departments.

The problem is that some Windows developers really want to have the "platform standard" naming scheme where static libraries have the suffix .lib, shared libraries have .dll and import libraries have .lib. The reason Meson does not do that is that then you could not build a shared and static version of the same library at the same time (because the file names would clash). Which is a thing that a different set of people really want.

You can't really know the correct extension in advance, either, there are people who use MinGW to build libs that will be consumed by MSVC projects. It's all terribly complicated.

A reasonable compromise is to do what Rust does and make the import library have the extension '.dll.lib`. But that would be a backwards incompatible change.

Ergo this MR.

[bonzini]

Ok, then I think for this feature to be complete:

• cygwin style should indeed be added (cyg*.dll, lib*.dll.a, lib*.a)
• there is no need for any other convention than: 1) "meson", 2) "platform", which would coincide with meson on non-windows hosts and would be either the cygwin or the rustc convention, 3) if we really want to support .so on macOS, something else like "posix" or "elf" (?) or "so", which would not be available on Windows (setup time failure)
• https://mesonbuild.com/FAQ.html#why-does-building-my-project-with-msvc-output-static-libraries-called-libfooa should be extracted into a new section "Naming conventions" or something like that, and replaced by a stub that points to the new section

[jpakkane]

We can add new option value later, but those two seem a bit inadequate. Should the "platform" one do .dll.lib or .lib? There is no clear answer for this due to the file name clash. Not to mention that the default should probably be the same as now. Personally I'd very much like to change it to do .dll.lib and convert .a to .lib but that has fairly high breakage potential.

[jpakkane]

Changed to align the recommended way.

Is this enough for Windows devs or will someone still insist on having plain .lib on both files? I don't know.

[bonzini]

The conversion from "platform" to dictionary key should be in a separate function.

I would change namingscheme to libnames or something like that.

Also it's not clear to me why it's ok to change the default, I will trust you :) but maybe the implications of the change should be in the release notes?

[jpakkane]

Also it's not clear to me why it's ok to change the default, I will trust you

An open question is whether this should be changed now or later. The new option is "better" in the sense that is more native to each platform. Maybe we can add this now and change the default in 1.11 or something like that?

[dcbaker]

I don't think we can reasonably change the default until we do a 2.0, the change is going to break some project somewhere, and if an upstream really wants to rely on the new setting they can add it to their project() call along with meson_version : '>= 1.10'

[jpakkane]

Made classic the default.

[dcbaker]

LGTM