Ответ 1
Возможно, я что-то пропустил, но почему вы не можете определить проект DLL без файлов и просто связать lib, созданный другим проектом? И, в отношении настроек, вы можете разложить их в файлах vsprop...
Создание как DLL, так и статических libs из того же проекта
У меня есть несколько собственных библиотек С++ (Win32, без MFC), которые компилируются в Visual Studio 2005 и используются в ряде решений.
Я хотел бы иметь возможность выбирать, компилировать и связывать их как статические библиотеки или библиотеки DLL, в зависимости от потребностей конкретного решения, в котором я их использую.
Какой лучший способ сделать это? Я рассмотрел эти подходы:
1. Несколько файлов проекта
- Пример: "foo_static.vcproj" vs "foo_dll.vcproj"
- Pro: легко создавать для новых библиотек, не слишком много ручного vcproj munging.
- Con: настройки, списки файлов и т.д. в двух местах слишком легко выходят из синхронизации.
2. Один файл проекта, несколько конфигураций
- Пример: "Debug | Win32" против "Debug DLL | Win32" и т.д.
- Pro: списки файлов легче синхронизировать; варианты компиляции несколько проще синхронизировать.
- Con: Я строю для целей Win32 и Smart Device, поэтому у меня уже есть несколько конфигураций; Я не хочу усиливать мой комбинаторный взрыв ( "Статическая библиотека для FooPhone | WinMobile 6", "Динамическая библиотека для FooPhone | WinMobile 6", "Статическая библиотека для BarPda | WinMobile 6" и т.д.
- Хуже Con: VS 2005 имеет плохую привычку предполагать, что если у вас есть конфигурация, определенная для платформы "Foo", тогда вам это действительно нужно для всех других платформ вашего решения и беспорядочно вставляет все перестановки конфигураций/конфигурации платформы по всем затронутым файлам vcproj, независимо от того, действительны они или нет. (Ошибка, поданная с MS, закрыта как WONTFIX.)
3. Один файл проекта, выбор статического или динамического с помощью файлов vsprops
- Пример: сохраните соответствующие фрагменты vcproj в файлах свойств, затем примените лист свойств "FooApp Static Library" в комбинации конфигурации/платформы, когда вы хотите статические библиотеки, и примените лист свойств "FooApp DLL", когда вам нужны библиотеки DLL.
- Плюсы: Это то, что я действительно хочу сделать!
- Минусы: Это не представляется возможным. Кажется, что .vcproj-атрибут, который переключается между статическими и динамическими библиотеками (атрибут ConfigurationType элемента Configuration), не переопределяется .vsprops файл. Опубликованная схема Microsoft для этих файлов содержит только те элементы <Tool> и <UserMacro> .
EDIT. В случае, если кто-то подскажет это, я также попробовал более "умную" версию №3, в которой я определяю .vsprops, содержащий UserMacro с именем "ModuleConfigurationType" со значением либо "2" (DLL), либо "4" (статическая библиотека), и изменили конфигурацию в .vcproj, чтобы иметь ConfigurationType="$(ModuleConfigurationType)". Visual Studio молча и без предупреждения удаляет атрибут и заменяет его ConfigurationType="1". Так полезно!
Не хватает ли лучшего решения?
Ответы
Ответ 2
Существует простой способ создания как статических, так и DLL-версий lib в одном проекте.
Создайте проект dll. Затем сделайте следующее:
Просто создайте файл makefile nmake или .bat, который запускает инструмент lib. В основном, это именно так:
lib /NOLOGO /OUT:<your_lib_pathname> @<<
<list_all_of_your_obj_paths_here>
<<
Затем в вашем проекте добавьте событие Post Build, в котором команда запускает файл .bat(или nmake или perl). Затем вы всегда получите как dll, так и статическую lib. Я воздержусь от очернения визуальной студии за то, что она не позволяет инструменту для этого существовать в проекте непосредственно перед компоновщиком (в потоке инструмента).
Ответ 3
Я думаю, что типичным способом это является выбор 2 выше. Это то, что я использую, и то, что я видел, сделал ряд библиотек и компаний.
Если вы обнаружите, что это не сработает для вас, то обязательно используйте что-то еще.
Удачи.
Ответ 4
Я предпочитаю 2 способа конфигурации.
Установите все общие настройки с помощью элемента "Все конфигурации" в окнах свойств проекта. После этого отделяются настройки. И все. Пусть идет кодирование.
Также есть очень хорошая функция с именем "Batch build", которая строит указанные конфигурации по очереди.
Ответ 5
Несколько проектов - лучший способ пойти - это конфигурация, которую я наиболее широко видел в бесчисленных проектах, с которыми я столкнулся.
Тем не менее, возможно также реализовать третий вариант, изменяя ваши файлы vcproj "на лету" из внешних инструментов (например, пользовательский vbscript), которые вы могли бы вызывать из файла make. Вы можете использовать переменные оболочки для управления поведением инструмента.
Обратите внимание, что вы все равно должны использовать визуальную студию для создания сборки, makefile должен запускать внешний инструмент, если это необходимо для создания модов, а затем следовать этому с помощью команды сборки
Ответ 6
Почему бы не перейти к версии 1 и сгенерировать второй набор файлов проекта из первого, используя script или что-то еще. Таким образом, вы знаете, что различия - это просто части, необходимые для создания dll или статической библиотеки.
Ответ 7
Я использую Visual Studio 6.0 (все еще) из-за проблем, которые мешают нам переходить на VS2005 или новее. Реконструкция вызывает серьезные проблемы (все ломается)... многие из нас рассматривают возможность лоббирования перехода на GnuС++ в структурированном виде, чтобы в конечном итоге избавить нас от лицензированных продуктов Visual Studio и на Eclipse и Linux.
В Unix/Linux его легко построить для всех конфигураций. Поэтому я не могу поверить, что время и производительность сводятся к тому, чтобы попытаться выполнить одну и ту же задачу в Visual Studio. Для VS6.0 я до сих пор нашел, что только наличие двух отдельных проектов представляется работоспособным. Я еще не пробовал метод множественной конфигурации, но увижу, работает ли он в старом VS6.0.