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.

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.

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?

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.

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.

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.

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

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.