Как должны быть названы специфичные для платформы файлы lib? - PullRequest
Новая
       16

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

1 голос
/ 18 марта 2010

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

  1. Win32 Debug Dynamic
  2. Win32 Static Debug
  3. Win32 Release Dynamic
  4. Win32 Release Static
  5. x64 Dynamic Debug
  6. x64 Статическая отладка
  7. x64 Release Dynamic
  8. x64 Release Static

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

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

Ответы [ 3 ]

2 голосов
/ 18 марта 2010

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

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

2 голосов
/ 18 марта 2010

Я думаю, что 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, чтобы выяснить, какую библиотеку использовать. Если вы сделаете все возможное и предоставите статические и динамические библиотеки для всех параметров, вам потребуется дополнительное определение, например NETINFO_USE_STATIC_LIB. чтобы определить, стоит ли использовать динамический или статический аромат.

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

1 голос
/ 18 марта 2010

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

...