2012-05-14 2 views
0

Мы используем CMake для создания файлов решений для Visual Studio 2008. В дополнение к обычным исходным проектам, которые создают библиотеки и исполняемые файлы, я хотел бы иметь проект, содержащий только файлы конфигурации. Эти файлы используются для настройки поведения проекта во время выполнения. Они не нужны для создания проекта, но включение их в решение позволяет удобно редактировать эти файлы. Я был в состоянии сделать это, используя add_custom_target так:Как создать CMake проект Visual Studio, содержащий только файлы конфигурации?

file(GLOB ini_files ${PROJECT_SOURCE_DIR}/../config/ini/*) 
source_group(ini FILES ${ini_files}) 
file(GLOB xml_files ${PROJECT_SOURCE_DIR}/../config/xml/*) 
source_group(xml FILES ${xml_files}) 
add_custom_target(config SOURCES ${ini_files} ${xml_files}) 

Это дает мне «конфигурации» проект, который содержит конфигурационные файлы как папки. Тем не менее, есть ссылка с именем «config» на какой-то несуществующий файл. Я предполагаю, что это должна быть ссылка на цель, созданную этим правилом. Поскольку ничего не нужно строить, это останется мертвой ссылкой. Теперь я задаю следующие вопросы:

  1. Является ли add_custom_target правильным способом для выполнения того, что я хочу? Если нет, то что было бы лучшим решением?
  2. Если это правильный способ, как я могу избавиться от ссылки на имя цели? Кроме того, я хотел бы удалить папку «Правила CMake», чтобы сделать проект конфигурации максимально чистым.

ответ

2

Проекты Visual Studio по существу предназначены для создания целей в зависимости от набора исходных файлов.

Наличие проекта, который существует только для того, чтобы перечислить набор статических файлов, не рекомендуется, так как, как только вы добавляете настраиваемую цель, CMake слепо попытается создать выход для проекта, чтобы оставаться совместимым с другими бэкэнд-системы. Только представьте, если CMake создал Unix Makefile без реальной цели, это даже не будет Makefile, не так ли?

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

Кроме того, я не могу рекомендовать использование globing файлов для отображения исходных файлов или файлов конфигурации, потому что если вы добавляете файлы в папки, CMake не будет знать, что новые файлы были добавлены, а проект Visual Studio не будут восстановлены, чтобы включить эти файлы. Вместо этого вы должны перечислить каждый файл в файлах CMakeLists.txt, так что добавление нового файла приведет к регенерации файлов cmake.

В последнем случае, если вам действительно нужны «чистые» проекты, то CMake - это не тот инструмент, который вам нужен, потому что все, что он создает, полезно для поддержания последовательного процесса сборки.

+0

Спасибо за этот проницательный ответ. Добавляя файлы к существующему проекту, я имел в виду сам; проблема в том, что проекты фактически строят модули (динамические библиотеки, DLL или так файлы), которые используются инфраструктурой, внешней по отношению к нашим проектам. Поэтому, возможно, можно было бы поместить файлы конфигурации в модули, к которым они принадлежат; некоторые из них используются несколькими. Существуют также файлы, которые настраивают инфраструктуру для использования модулей и, таким образом, не читаются никаким модулем. Я знаю, что для Unix Make-файлов это не было бы полезно, но единственная цель этого проекта - добавить файлы конфигурации в VS. – ahans

+0

@ahans Ничто не мешает вам включать файлы в несколько проектов. Накладные расходы минимальны, поскольку файл не будет дублироваться. – SirDarius

+0

Интересная точка. Это не решает проблему с файлами, настраивающими структуру. Я буду держать это в виду, может пригодиться в какой-то момент. Пока я решил это, используя 'add_library'; это делает именно то, что я хотел. – ahans

Смежные вопросы