2010-07-09 6 views
16

Вопрос: Может ли CMake генерировать скрипты сборки, которые каким-либо образом не используют CMake? Если нет, то как трудно заставить кинематографический скрипт, созданный в CMake, не делать никаких проверок против CMake?Может ли CMake генерировать скрипты сборки, которые * не * используют cmake?

Я большой поклонник CMake до такой степени, что я отстаиваю идею, что мы переходим к ней в моей текущей рабочей среде. Одна вещь, которая могла бы облегчить этот переход от нашей текущей системы сборки к CMake, была бы, если бы я мог продемонстрировать, что CMake может генерировать файлы automake, которые сами не требуют cmake.

Очевидно, что я никогда не захотел бы этого делать для повседневного использования, но имея возможность легко создать ветвь нашего кода, который может быть построен из источника, не требуя cmake, будет иметь большое значение, помогая мне сделать мой дело.

+0

Мне показалось странным, что ответы здесь «нет». Я просто добираюсь до точки с cmake, что я начинаю понимать, как использовать его (вместо того, чтобы пытаться заставить его делать что-то, для чего он не предназначен), например, используя сборку вне источника и т. Д. Но я что cmake в комплекте с cpack, который может генерировать tarballs на Linux и тому подобное. Если tarball требует создания cmake, я не уверен, что это tarball вообще. – Steve314

+0

Я рассмотрю CPack;) – Voltaire

+3

Файлы tarball, созданные CPack, обычно не являются исходными tarball для построения, а скорее бинарными tarball для запуска системы. – JesperE

ответ

5

Нет, CMake не может этого сделать. Это тоже не имеет смысла, поскольку без поддержки CMake во время сборки не было бы возможности проверить или обновить сами файлы makefile/project-файлов при изменении файлов CMakeLists.txt.

Если вы переезжаете с Visual Studio на CMake, вы можете взглянуть на vcproj2cmake.

+1

Это на самом деле «желаемое» следствие. Меня интересует создание автоматических инструментов, готовых к распространению «вида сборки», где make может быть использован для создания проекта без зависимостей cmake любого вида - в этот момент это нормально если изменения не отражаются в CMake. – Voltaire

+5

Это пример использования, который CMake не адресует. – JesperE

2

Как человек, который взял большое комплексное программное обеспечение и недавно вытащил свою существующую систему сборки, установив на ее место новую систему сборки. Я могу сказать вам, что это непросто, но я бы определенно не хотел, чтобы сценарии оболочки были частью моего процесса сборки, если их можно избежать. В любом случае все больше и больше систем окажутся с CMake, так как более крупные программные пакеты, такие как LLVM и KDE, начнут использовать его. Это область, где она действительно распространяется, большие проекты.

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

3

Файлы сгенерированных CMake зависят от cmake для различных команд, таких как create/remove/etc ... не только для того,

+2

+1 CMake также можно использовать в качестве языка сценариев (см. Параметр «-P» в man-странице CMake), а многие проекты используют CMake в качестве замены сценариев оболочки, например, для копирования файлов или вызова вспомогательных программ. Эти проекты потребуют CMake во время сборки, а не только для создания make-файла. – sleske

-1

Как насчет «атомного решения»?

EX- автоматической генерации "QT MOC" файл из CMakeLists.txt, а затем построить проект, который зависит от файла .cpp генерируется

# inside project level CMakeLists.txt 
# run shell script to create the "moc_GUICreator.cpp" auto-generated source file 
if(UNIX) 
execute_process(COMMAND "sh" ${CMAKE_CURRENT_SOURCE_DIR}/scripts/generate_moc.sh WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/scripts) 
endif(UNIX) 

Где .sh файл содержит:

# generate_moc.sh 
echo "generating moc file: moc ../include/GUICreator.h -o ../src/moc_GUICreator.cpp " 
moc ../include/GUICreator.h -o ../src/moc_GUICreator.cpp 

Эквивалентные окна пакетный файл, "moc_creator_win.bat":

moc "GUICreator.h" -o "moc_GUICreator.cpp" 

не пробовал эту л аст немного в окнах, но это или что-то очень близко должно работать, только после того, если (UNIX) блока в CMakeLists.txt:

if(WIN32) 
execute_process(COMMAND "cmd" ${CMAKE_CURRENT_SOURCE_DIR}/scripts/moc_creator_win.bat WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/scripts) 
endif(WIN32) 

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

дело в том, чтобы избежать «непортабельной типа сборки», если вам действительно нужно взломать его в специализированный компилятор, или не чувствуют, как с помощью Qt Designer, чтобы разместить виджеты ;-)

+0

Я не уверен, что это относится к исходному вопросу. –

+0

Точка, в которой вы можете использовать CMake, как предполагалось, или на противоположном конце спектра, просто оберните ее вокруг произвольных скриптов. Нет ничего, что помешало бы вам разобрать переменные cmake и генерировать любые make-файлы, которые вы хотите ... –

4

Способности для этого зависит от вашей ОС, я предполагаю Unix/Makefile или Winderz/MSVC. Если вы используете MSVC, зависимость cmake должна быть устранена, объявив параметр CMAKE_SUPPRESS_REGENERATION в начале вашего сценария cmake.

SET(CMAKE_SUPPRESS_REGENERATION TRUE) 

В системах Unix на основе, однако, в makefileах tied явно в CMake строить файлы (CMakeFiles и т.д.). Я подозреваю, что эта зависимость может быть обойдена стратегическим комментарием директив Makefile, хотя я не могу сказать, какими они могут быть.

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