How should platform specific lib files be named?_问答_开发者

I'm working on a C++ project that produces a lib that other teams use. It's being produced in a few different flavours:

Win32 Debug Dynamic
Win32 Debug Static
Win32 Release Dynamic
Win32 Release Static
x64 Debug Dynamic
x64 Debug Static
x64 Release Dynamic
x64 Release Static

I'm wondering what the best wisdom is on how to name the dlls and what arguments are for different naming conventions. Do I output the libs into different directories, or do I appen开发者_运维百科d some letters on the end of the lib to differentiate them, or something else? One concern is that if I use directories, but don't give all the libs different names, users of the library will have problems where they accidentally use the wrong lib. Are these concerns valid?

Thanks very much.

Using the Microsoft convention might be a good idea. The static version is prefixed "lib". The debug version is post-fixed "d". The 64-bit version goes in the amd64 subdirectory. Not the greatest convention but at least it is familiar.

In MSVC, you can use the predefined _DLL macro to detect that the user selected the DLL version of the CRT. The _WIN64 macro is defined if the 64-bit compilation is selected. Enough to generate the required #pragma comment(lib, "name") directive.

I think boost handles this by naming the .lib files after the specific platform. I like including the following pieces of information:

compiler major version (i.e. "vc80", "vc91", etc)
runtime version (i.e. "mt", "mdd", etc)
your library version (i.e "1.0", "2.1.1234", etc)

For instance, if your library is named "NetInfo", it is version 1.2.3, it was linked with debug CRT dynamically, and it was built with Visual Studio 2005:

NetInfo_1.2.3_vc80_mdd

The only thing to worry about is how people will consume your library: statically or dynamically. The way I usually do it is as follows:

If your library links to dynamic CRT, your library is provided as a DLL; otherwise, your library is provided as a static lib. The reasoning is that if people are dynamically linking with CRT then it's safe to assume they don't mind dynamically linking with your library. If you want to provide both options then I usually stick a "s" on the end to indicate it is a static library; the lack of a "s" indicates it is a dynamic library.

Example:

NetInfo_1.2.3_vc80_mdds.lib - static library, links with dynamic debug CRT
NetInfo_1.2.3_vc80_mds.lib  - static library, links with dynamic release CRT
NetInfo_1.2.3_vc80_mtds.lib - static library, links with static debug CRT
NetInfo_1.2.3_vc80_mts.lib  - static library, links with static release CRT
NetInfo_1.2.3_vc80_mdd.lib  - import library, links with dynamic debug CRT
NetInfo_1.2.3_vc80_mdd.dll  - dynamic library, links with dynamic debug CRT
NetInfo_1.2.3_vc80_md.lib   - import library, links with dynamic release CRT
NetInfo_1.2.3_vc80_md.dll   - dynamic library, links with dynamic release CRT
NetInfo_1.2.3_vc80_mtd.lib  - import library, links with static debug CRT
NetInfo_1.2.3_vc80_mtd.dll  - dynamic library, links with static debug CRT
NetInfo_1.2.3_vc80_mt.lib   - import library, links with static release CRT
NetInfo_1.2.3_vc80_mt.dll   - dynamic library, links with static release CRT

This method is a little extra work, but it covers all the bases. If you are providing different platforms then you should also stick "x86" and "x64" on there.

Then in your header file you can use _WIN64, _DLL, and _DEBUG macros to figure out which library to pull in. If you go all out and provide static and dynamic libraries for all options then you will need an additional define like NETINFO_USE_STATIC_LIB to determine whether to pull in the dynamic or static flavor.

This method allows you to keep all the files in the same directory and lets you know the specifics just by looking at the name of the file. The downside is that some people might complain about loading a verbosely named dll instead of a simple "NetInfo.dll" (especially if they are using LoadLibrary), but that's really a minor issue. Doesn't seem to deter people from using boost.

I output all the different flavours into the same directory, using a naming convention to disambiguate. By having them in the same directory, the linker directories don't have to change between flavour. The libraries then get linked using a set preprocessor directives that select the #pragma (lib,...) directive for the flavour being compiled.