On most platforms, libraries typically have a prefix of lib, but on some (notably Windows), there is typically no prefix. We currently handle these differences through the CMAKE_FIND_LIBRARY_PREFIXES variable, which is typically set by the platform files like Modules/Platforms/Windows.cmake and so on. In a recent commit (not yet in any CMake release), the fallback for when this variable isn’t defined (e.g. when CMake is run in script mode) was changed to the following:
That fallback now allows lib as a prefix on Windows where it didn’t before. But that fallback should never get used in project mode, since Modules/Platforms/Windows.cmake explicitly sets CMAKE_FIND_LIBRARY_PREFIXES to an empty string, which means prefixProp in the above will see that empty string and use it instead of the hard-coded defaultPrefix.
But as highlighted by the linked Qt issue, sometimes libraries will still have a lib prefix, even on Windows (it is libEGL in that case, which is hard-coded by the .gn files for that project’s build system). This raises the question of whether we should still consider a lib prefix, even on Windows. We already will be for script mode due to the above-mentioned change, so there’s also an issue of consistency here. So I’d like to raise the following questions for discussion:
Would it make sense to set CMAKE_FIND_LIBRARY_PREFIXES to ;lib or lib on Windows too?
Would that result in any danger or change in behavior which would need a policy?
I would suggest lib; as the default on all platforms. It is the wild west out there regarding useless lib prefixes (because the subfolder/extension already defines the file type)
File list of x64-windows in vcpkg filtered by the regex lib/lib.+\.lib (Not all will probably follow upstream behavior but most of them will)
The convention used on Windows often differs based on whether one is targeting the MSVC ABI or the GNU ABI (MinGW):
For the MSVC ABI, some projects use foo.{dll,lib} for shared libraries and libfoo.lib for the corresponding static library. CMake encodes only the shared library convention in Platform/Windowshere. Using ;lib would preserve that historical preference, but may affect what gets found differently depending on whether NAMES_PER_DIR is used in the find_library call.
For the GNU ABI (MinGW), the convention is typically libfoo.{dll,dll.a} for shared libraries and libfoo.a for static libraries. CMake encodes the convention in Platform/Windows-GNUhere.
source? Not even autotools with MSVC wrappers does that. Meson even does libfoo.a on windows for static libs (meson just decided to be incompatible with everything for static builds. )
some projects use foo.{dll,lib}
autotools even does .dll.lib. vcpkg patches this to .lib due to compatibility with cmake and not having to fix every pkg-config file by adding a .dll suffix into the -l flags.
It is also more what the compiler/linker vendors decided to be the default outputs instead of a “convention”. So libfoo.lib certainly doesn’t fall into that category (which also requires fixing pkg-config files to add the lib prefix into the -l flags…).
Using libfoo.lib for static libraries with the MSVC ABI is a boost convention. I’ve seen other projects follow the convention too, but I don’t know if any build system standardizes on it by default.
autotools even does .dll.lib.
For the GNU ABI we already use .dll.a, so I think equivalently searching for both .dll.lib and .lib extensions for the MSVC ABI would be fine.
The reason for such a “convention” is just justified by the fact that people commonly want to have every library type in the same folder. On linux this is taken care of by the suffixes e.g. .a vs .so. The same goes for configuration DEBUG (“d”) suffixes.
On windows this can be achieved by either adding add lib prefix to the static library or by using a .dll.lib. Syntactically only the later really makes sense since adding a lib prefix is simply a doubling of the suffix .lib while .dll.lib undoubtedly could be made the symbol for a shared library.
But really there is no “convention”. At least I don’t see one, its just all some random prefixes and suffixes for me ;).
The reason I selected this order was that -P mode could capture both GNU ABI and MSVC ABI with a measure of success. In this case anything that worked with MSVC ABI would continue to work as expected, and GNU ABI would potentially work.