Отказ от ответственности: есть несколько видов варенья. Ответ относится к Perforce Jam и некоторым его совместимым потомкам.
Как вы уже упоминали, вызывать jam из cmake можно с помощью add_custom_target
/ add_custom_command
, так что ответ на первую часть Ваш вопрос.
Поскольку правила варенья (или, скорее, действия) могут вызывать произвольные команды, конечно, возможно и другое направление. cmake
сам по себе обычно не является инструментом, который вы вызываете для построения цели. Так что, в зависимости от вашего генератора, вы на самом деле захотите позвонить make
, ninja
, ...
В своем вопросе вы не очень конкретны в отношении вашего подхода к миграции. Предполагается, что вы начинаете с системы сборки с использованием нескольких библиотек и исполняемых целей, которые охватывают граф зависимостей, и вы хотите переносить систему сборки компонент за компонентом. Если вы начнете работу с библиотекой без зависимостей (источники которой, предположительно, находятся в своем собственном подкаталоге), вы бы заменили вызов правила, который создает библиотеку, например Library libfoo : foo.c bar.c ;
, вызовом правила, который вызывает, например, make
- - как Make libfoo$(SUFLIB) ;
. Правило может быть определено (например, в Jamrules
) как:
rule Make
{
# tell jam where the target will be created
MakeLocate $(1) : $(LOCATE_TARGET) ;
# always invoke the actions, since we don't let jam check the target's dependencies
Always $(1) ;
# we need the source dir in the actions
SOURCE_DIR on $(1) = $(SUBDIR) ;
}
actions Make
{
# get absolute source dir path
sourceDir=`cd $(SOURCE_DIR) && pwd`
# cd into the output directory
cd $(LOCATE)
# generate Makefile, if not done yet
if [ ! -e Makefile ]; then
cmake -G "Unix Makefiles" $(sourceDir) ;
fi
# make the target
make `basename $(1)`
}
Если вам нужна другая информация из jam для передачи в cmake (например, тип сборки или определенные параметры сборки), определите соответствующие целевые переменные (например, SOURCE_DIR
в примере), чтобы они были доступны в действиях.