Как должны называться файлы lib для конкретных платформ?

Я работаю над проектом C++, который создает библиотеку, которую используют другие команды. Он производится в нескольких разных вкусах:

  1. Динамическая отладка Win32
  2. Статическая отладка Win32
  3. Динамический выпуск Win32
  4. Статическая версия Win32
  5. Динамическая отладка x64
  6. x64 Отладка Статическая
  7. x64 выпуск динамический
  8. Статическая версия x64

Мне интересно, какова наилучшая мудрость в том, как назвать библиотеки DLL и какие аргументы существуют для различных соглашений об именах. Должен ли я выводить библиотеки в разные каталоги, или я добавляю некоторые буквы в конец библиотеки, чтобы различать их, или что-то еще? Одна проблема заключается в том, что если я использую каталоги, но не даю всем библиотекам разные имена, у пользователей библиотеки будут проблемы, когда они случайно используют неправильную библиотеку. Правомерны ли эти опасения?

Большое спасибо.


c++ static-libraries dll shared-libraries
person Scott Langham    schedule 18.03.2010    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Я вывожу все разные варианты в один и тот же каталог, используя соглашение об именах для устранения неоднозначности. Имея их в одном и том же каталоге, каталоги компоновщика не должны меняться между вариантами. Затем библиотеки связываются с помощью набора директив препроцессора, которые выбирают директиву #pragma (lib,...) для компилируемого варианта.

person JoeG    schedule 18.03.2010
comment
Хм, да, хороший момент, я не думал об использовании #pragma (lib). Это будет хорошо работать для выбора правильной платформы и конфигурации. Но, возможно, это не так хорошо для выбора между динамическими и статическими библиотеками. Возможно, пользователь может указать #LIBRARYNAME_STATIC или #LIBRARYNAME_DLL или что-то еще в настройках своего проекта, чтобы сделать этот выбор. Как вы думаете, это сработает? - person Scott Langham; 18.03.2010
comment
Ах, я думал, что динамический/статический относится к тому, связана ли библиотека с динамической CRT или статической CRT. Вам придется использовать какой-то пользовательский #define, если вы пытаетесь выбрать между статической и динамической ссылками. - person JoeG; 18.03.2010

arrow_upward
2
arrow_downward

Использование соглашения Microsoft может быть хорошей идеей. Статическая версия имеет префикс «lib». Отладочная версия имеет постфикс "d". 64-битная версия находится в подкаталоге amd64. Не самая большая условность, но, по крайней мере, знакомая.

В MSVC вы можете использовать предопределенный макрос _DLL, чтобы определить, что пользователь выбрал DLL-версию CRT. Макрос _WIN64 определяется, если выбрана 64-битная компиляция. Достаточно для создания необходимой директивы #pragma comment(lib, "name").

person Hans Passant    schedule 18.03.2010

arrow_upward
2
arrow_downward

Я думаю, что boost справляется с этим, называя файлы .lib в честь конкретной платформы. Мне нравится включать следующие части информации:

  1. основная версия компилятора (например, «vc80», «vc91» и т. д.)
  2. версия среды выполнения (например, «mt», «mdd» и т. д.)
  3. версия вашей библиотеки (например, «1.0», «2.1.1234» и т. д.)

Например, если ваша библиотека называется «NetInfo», это версия 1.2.3, она была динамически связана с отладочной CRT и была собрана с помощью Visual Studio 2005:

NetInfo_1.2.3_vc80_mdd

Единственное, о чем стоит беспокоиться, так это о том, как люди будут потреблять вашу библиотеку: статически или динамически. Обычно я делаю это следующим образом:

Если ваша библиотека связана с динамической CRT, ваша библиотека предоставляется в виде DLL; в противном случае ваша библиотека предоставляется как статическая библиотека. Причина в том, что если люди динамически связываются с CRT, то можно с уверенностью предположить, что они не возражают против динамического связывания с вашей библиотекой. Если вы хотите предоставить оба варианта, я обычно добавляю «s» в конце, чтобы указать, что это статическая библиотека; отсутствие буквы «s» указывает на то, что это динамическая библиотека.

Пример:

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

Этот метод требует немного дополнительной работы, но он охватывает все основы. Если вы предоставляете разные платформы, вам также следует вставить туда «x86» и «x64».

Затем в заголовочном файле вы можете использовать макросы _WIN64, _DLL и _DEBUG, чтобы определить, какую библиотеку использовать. Если вы сделаете все возможное и предоставите статические и динамические библиотеки для всех параметров, вам потребуется дополнительное определение, например чтобы привлечь динамический или статический аромат.

Этот метод позволяет хранить все файлы в одном каталоге и позволяет узнать подробности, просто взглянув на имя файла. Недостатком является то, что некоторые люди могут жаловаться на загрузку dll с подробным названием вместо простой «NetInfo.dll» (особенно если они используют LoadLibrary), но это действительно незначительная проблема. Кажется, это не удерживает людей от использования наддува.

person Luke    schedule 18.03.2010