2017-02-04 3 views
1

Моя команда обсуждает переход на CMake для нашей среды разработки. Наше программное обеспечение состоит (по большей части) из двух основных приложений:CMake с несколькими взаимозависимыми проектами

ProcessingHub - получает информацию от датчиков, обрабатывает ее и транслирует.

Клиент - Получает передачу данных от ProcessingHub и предоставляет дружественный API для извлечения данных.

Обе части программного обеспечения - в дополнение ко многим другим проектам - используют статическую библиотеку в качестве уровня интерфейса ОС; Я назову это OsInterfaceLib.

ProcessingHub также использует две другие статические библиотеки, которые считаются независимыми библиотеками, поскольку они предназначены не только для использования с ProcessHub. Я назову их ProcessingLib и SensorLib.

Наша СВН структура выглядит следующим образом:

  • ствол
    • ProcessingHub
    • Client
    • OsInterfaceLib
    • ProcessingLib
    • SensorLib

Наши рабочие пространства на диске точно отражают SVN.

В настоящий момент мы используем проверенные проекты Visual Studio и Eclipse для Windows и Linux соответственно. В Windows, ProcessingLib должен быть построен с помощью Clang. Windows - наша основная платформа, и у ProcessHub/Client есть решения VS, которые содержат необходимые зависимые проекты, так как все эти проекты постоянно развиваются и возможность отладки через проекты без проблем имеет первостепенное значение.

Я провел целую рабочую неделю с полной занятостью, изучая CMake, и кажется, что единственный способ получить CMake для создания VS-решения, в котором есть все необходимые зависимые проекты, - использовать команду add_subdirectory для каждой зависимости , Это не с помощью ProcessLib, поскольку оно должно быть построено с другой цепочкой инструментов, чем другие. Насколько мне известно, цепочку инструментов можно установить только во время вызова cmake, поэтому генерация всего за один выстрел из обработчика верхнего уровня ProcessHub или Client CMakeLists.txt не будет работать.

Мой вопрос заключается в следующем: Является ли держать наши проекты так, как они лучше голос, или есть чистый, простой способ иметь CMake:

  1. Генерация ProcessingHub и клиент решения с необходимыми зависимыми проектами уже в решение исследователь
  2. Используйте тот же исходный код и сгенерированные файлы проекта для OsInterfaceLib
  3. Не требует перестройки нашего SVN/извлеченного рабочее пространство

ответ

1

Вы можете установить компилятор C++ через переменную CMAKE_CXX_COMPILER, но обратите внимание, что это должно быть сделано перед любыми project() или enable_language().

Наивный подход будет вызывать project() в поддиректории:

верхнего уровня CMakeLists.txt:

add_subdirectory(ProcessingLib) 
add_subdirecdory(Others) 

ProcessingLib CMakeLists.txt:

set(CMAKE_CXX_COMPILER /path/to/clang) 
project(ProcessingLib) 

... 

Другие CMakeLists.txt:

project(Others) 

... 

Но, глядя в документации project():

верхнего уровня CMakeLists.txt файла для проекта должен содержать буквальный, прямой вызов команды project(); загрузка одного через команду include() недостаточна. Если такой вызов не существует, CMake будет неявно добавлять один к вершине, который позволяет использовать языки по умолчанию (C и CXX).

Так AFAIK лучшее, что вы можете сделать, это построить ProcessingLib как external project вместо поддиректории:

include(ExternalProject) 
ExternalProject_Add(ProcessingLib 
    SOURCE_DIR /path/to/ProcessingLib 
    CMAKE_ARGS -DCMAKE_CXX_COMPILER=/path/to/clang 
) 
+0

Это работает, если параметр '' CMAKE_GENERATOR' и CMAKE_ARGS' в команды 'ExternalProject_Add'. 'add_library ( STATIC IMPORTED' также требуется для установки цели, которая может быть связана с исполняемым файлом. Однако vcxproj, сгенерированный на импортированных библиотеках, кажется, является оболочкой, которая просто запускает cmake в своей директории - нет Source, Header, Фильтры ресурсов заполняются в обозревателе решений – Timmah339