Сборка DLL и статических библиотек из одного проекта

Question

У меня есть несколько собственных библиотек C ++ (Win32, без MFC), компилируемых в Visual Studio 2005 и используемых в ряде решений.

Я бы хотел иметь возможность компилировать и связывать их как статические библиотеки или библиотеки DLL, в зависимости от потребностей конкретного решения, в котором я их использую.

Какой лучший способ сделать это? Я рассмотрел эти подходы:

1. Несколько файлов проекта

• Пример: "foo_static.vcproj" против "foo_dll.vcproj"
• Pro: легко генерировать для новых библиотек, не слишком много ручного запуска vcproj.
• Con: настройки, списки файлов и т. Д. В двух местах слишком быстро перестают синхронизироваться.

2. Один файл проекта, несколько конфигураций

• Пример: «Debug | Win32» против «Debug DLL | Win32» и т. Д.
• Pro: списки файлов легче синхронизировать; Варианты компиляции несколько проще синхронизировать
• Con: Я создаю для целей Win32 и Smart Device, поэтому у меня уже есть несколько конфигураций; Я не хочу усугублять свой комбинаторный взрыв («Статическая библиотека для FooPhone | WinMobile 6», «Динамическая библиотека для FooPhone | WinMobile 6», «Статическая библиотека для BarPda | WinMobile 6» и т. Д.
• Хуже всего то, что VS 2005 имеет дурную привычку полагать, что если у вас есть конфигурация, определенная для платформы "Foo", то она вам действительно нужна для всех других платформ в вашем решении, и случайным образом вставляет все перестановки конфигурации / конфигурации платформы все поврежденные файлы vcproj, действительные или нет. (Ошибка подана в MS; закрыта как WONTFIX.)

3. Отдельный файл проекта, выбор статического или динамического файла vsprops

• Пример: сохраните соответствующие фрагменты vcproj в файлах листов свойств, затем примените лист свойств «Статическая библиотека FooApp» к комбинациям конфигурации / платформы, когда вам нужны статические библиотеки, и примените лист свойств «FooApp DLL», когда вы хотите библиотеки DLL.
• Плюсы: Это то, что я действительно хочу сделать!
• Минусы: Это кажется невозможным. Кажется, что атрибут .vcproj, который переключается между статическими и динамическими библиотеками (атрибут ConfigurationType элемента Configuration), не может быть переопределен файлом .vsprops , В опубликованной Microsoft схеме для этих файлов перечислены только элементы и .

EDIT : В случае, если кто-то предлагает это, я также попробовал более «умную» версию # 3, в которой я определяю .vsprops, содержащий UserMacro, называемый «ModuleConfigurationType» со значением либо "2" (DLL) или "4" (статическая библиотека), и изменили конфигурацию в .vcproj, чтобы иметь ConfigurationType="$(ModuleConfigurationType)". Visual Studio без предупреждения удаляет атрибут и заменяет его на ConfigurationType="1". Так полезно!

Мне не хватает лучшего решения?

Answer 1

Возможно, я что-то пропустил, но почему вы не можете определить проект DLL без файлов, а просто связать библиотеку, созданную другим проектом? И, что касается настроек, вы можете выделить их в файлах vsprop ...

Answer 2

Существует простой способ создания статической и DLL-версии lib в одном проекте.

Создайте свой проект DLL. Затем сделайте следующее:

Просто создайте make-файл nmake или файл .bat, который запускает инструмент lib. По сути, это просто так:

lib /NOLOGO /OUT:<your_lib_pathname> @<<
<list_all_of_your_obj_paths_here>
<<

Затем в своем проекте добавьте событие Post Build, когда команда просто запускает файл .bat (или nmake или perl). Тогда вы всегда получите и DLL, и статическую библиотеку. Я воздержусь от клеветы на Visual Studio за то, что инструмент для этого не существует в проекте непосредственно перед Linker (в потоке инструментов).

Answer 3

Я предпочитаю 2 варианта конфигурации.

Установите все общие настройки с помощью пункта «Все конфигурации» в окнах свойств проекта. После этого разошлись настройки. И это сделано. Пойдемте кодирование.

Также есть очень хорошая функция под названием «Пакетная сборка», которая строит указанные конфигурации по очереди.

Answer 4

Я думаю, что типичный способ сделать это - вариант 2 выше. Это то, что я использую, и то, что я видел, сделано рядом библиотек и компаний.

Если вы обнаружите, что это не работает для вас, тогда непременно используйте что-то еще.

Удачи.

Answer 5

Я использую Visual Studio 6.0 (все еще) из-за проблем, которые мешают нам перейти на VS2005 или новее. Восстановление вызывает серьезные проблемы (все ломается) ... поэтому многие из нас рассматривают лоббирование перехода на GnuC ++, чтобы двигаться вперед структурированным образом, чтобы в конечном итоге вывести нас из лицензированных продуктов Visual Studio и на Eclipse и Linux.

В Unix / Linux его легко собрать для всех конфигураций ... поэтому я не могу поверить, что это время и производительность, которые нужно попробовать, чтобы выполнить ту же задачу в Visual Studio. До сих пор я обнаружил, что для VS6.0 возможно наличие только двух отдельных проектов. Я еще не пробовал метод множественной конфигурации, но посмотрим, работает ли он в более старой версии VS6.0.

Answer 6

Почему бы не перейти на версию 1 и сгенерировать второй набор файлов проекта из первого, используя скрипт или что-то в этом роде. Таким образом, вы знаете, что различия - это просто части, необходимые для создания библиотеки DLL или статической библиотеки.

Answer 7

Лучше всего использовать несколько проектов - это конфигурация, которую я чаще всего видел в бесчисленных проектах, с которыми мне приходилось сталкиваться.

Тем не менее, может быть также возможно реализовать третий вариант, изменяя ваши файлы vcproj на лету из внешних инструментов (таких как пользовательский vbscript), которые вы можете вызывать из файла make. Вы можете использовать переменные оболочки для управления поведением инструмента.

Обратите внимание, что вы все равно должны использовать Visual Studio для создания сборки, make-файл должен запускать ваш внешний инструмент только при необходимости для создания модов, а затем следовать действительной команде сборки