I am running into a problem where I want to run a bash script to modify the headers inside the framework. Please see below minimal example.
cmake_minimum_required(VERSION 3.20)
project(example)
add_library(${PROJECT_NAME} A.cpp A.h)
set_target_properties(${PROJECT_NAME} PROPERTIES FRAMEWORK TRUE PUBLIC_HEADER
A.h)
add_custom_command(
TARGET ${PROJECT_NAME}
POST_BUILD
WORKING_DIRECTORY $<TARGET_FILE_DIR:${PROJECT_NAME}>/Headers
COMMAND bash ${CMAKE_SOURCE_DIR}/do_something_to_the_headers_in_framework.sh)
However, this sometimes works correctly and sometimes it works incorrectly, and I am 99% sure it is because once the target is built, cmake internally runs a POST_BUILD add_custom_command that copies the headers into the framework. Therefore, there is no guarantee which POST_BUILD command runs first, if the command that copies the headers into the framework runs first, then the result will be correct. On the flip side, if my do_something_to_the_headers_in_framework.sh got executed first, the result will be incorrect.
Is there a way to append new POST_BUILD commands to existing ones so we can ensure the POST_BUILD commands are executed in the desired order?
Related
I have target for shared and want it to run command after build ONLY if the Target output file changed, or same for me if build is updating.
In my example command runes every time when I build project, but I need it to run Only if after build Target output file changed
cmake_minimum_required(VERSION 3.21)
project(myexp)
add_library(Example SHARED source.cpp)
set_target_properties(Example PROPERTIES
RUNTIME_OUTPUT_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/bin$<0:>"
)
add_custom_command(TARGET Example POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy $<TARGET_FILE:Example> ${CMAKE_CURRENT_SOURCE_DIR}/new
DEPENDS Example
)
DEPENDS doesnt work here
from documentation - add_custom_command
The second signature adds a custom command to a target such as a library or executable.
This is useful for performing an operation before or after building the target.
The command becomes part of the target and will only execute when the target itself is
built.
If the target is already built, the command will not execute.
maybe my understanding of this is wrong
is there a way to Multi-OUTPUT
THANK YOU
In cmake there is custom commands, which can run PRE_BUILD or PRE_LINK or POST_BUILD.
However, on most platforms, except Visual Studio apparently, PRE_BUILD and PRE_LINK are idendical.
There are plenty of posts here about this issue, all stating this fact but noone giving a possible solution to "acutally PRE BUILD do something".
I for example need to run a bash script which will create some headers (c and c++ headers) automatically, and the source depends on them being A.) available and B.) defining certain things.
Is there an alternative to the custom command in cmake? How is it possible to execute something before the cmake process takes over and starts compiling things?
add_custom_command(TARGET ${PROJECT_NAME}
PRE_BUILD <---------------------------------------- THIS IS PRE_LINK unfortunatelly!
COMMAND ../my_bash_script.sh
DEPENDS ${PROJECT_NAME}
VERBATIM
)
I want to copy qml files from source directory to build directory. Following script works fine only first time. When I change any of the *.qml files and run make, they are not copied to build folder, they are not updated. What am I doing wrong?
file(GLOB_RECURSE SOURCES *.cpp)
file(GLOB_RECURSE QMLS *.qml)
add_library(MyLib SHARED ${SOURCES} ${QMLS})
foreach(QmlFile ${QMLS})
add_custom_command(TARGET MyLib POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${QmlFile} $<TARGET_FILE_DIR:MyLib>)
endforeach()
While Angew's answer is good, it is possible to eliminate usage of additional target. For doing this, add_library call should use copied .qml files (instead of original ones, like in the script in the question post):
# This part is same as in Angew's answer
set(copiedQmls "")
foreach(QmlFile ${QMLS})
get_filename_component(nam ${QmlFile} NAME)
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${nam}
COMMAND ${CMAKE_COMMAND} -E copy_if_different ${QmlFile} ${CMAKE_CURRENT_BINARY_DIR}
DEPENDS ${QmlFile}
COMMENT "Copying ${QmlFile}"
VERBATIM
)
list(APPEND copiedQmls ${CMAKE_CURRENT_BINARY_DIR}/${nam})
endforeach()
# But instead of creating new target, we reuse library one.
add_library(MyLib SHARED ${SOURCES} ${copiedQmls})
When library target is built, it triggers non-sources files in add_library call to be updated (if there is corresponded add_custom_command call), but updating non-source files doesn't force library file to be rebuilt. This is why your original code doesn't work as expected.
Note, because .qml files are not recognized by CMake as sources, you doesn't need to set GENERATED property for them, as stated here.
Your are using the TARGET signature of add_custom_command, which means the commands are executed as part of building the TARGET. In your case, POST_BUILD, which means the commands will be run after the build of MyLib finishes. If MyLib is up to date and does not need to be re-built, the commands will not run.
You might want to use the output-generating signature (OUTPUT) instead. Something like this:
set(copiedQmls "")
foreach(QmlFile ${QMLS})
get_filename_component(nam ${QmlFile} NAME)
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${nam}
COMMAND ${CMAKE_COMMAND} -E copy_if_different ${QmlFile} ${CMAKE_CURRENT_BINARY_DIR}
DEPENDS ${QmlFile}
COMMENT "Copying ${QmlFile}"
VERBATIM
)
list(APPEND copiedQmls ${CMAKE_CURRENT_BINARY_DIR}/${nam})
endforeach()
add_custom_target(
CopyQMLs ALL
DEPENDS ${copiedQmls}
)
Note that unfortunately, the OUTPUT argument of add_custom_command does not support generator expressions, so $<TARGET_FILE_DIR> cannot be used there. I used ${CMAKE_CURRENT_BINARY_DIR} in the example above, you might need to customise this to suit your needs. ${CMAKE_CFG_INTDIR} can be used to specify the per-configuration directory for multiconfiguration generators.
Note the presence of the additional custom target in my code above. That's necessary, because CMake will only execute an output-producing custom command if something depends on that output. The custom command does that, by listing the outputs in its DEPENDS section.
Perhaps this is impossible and I'm misreading the cmake 3.2 documentation, but I though creating a custom command would create a custom "target" in the Makefile so that I could build the target by invoking the name of the output file. The CMake docs says:
In makefile terms this creates a new target in the following form:
OUTPUT: MAIN_DEPENDENCY DEPENDS
COMMAND
so I thought I could then run make OUTPUT. Perhaps the documentation is confusing CMake targets with Makefile targets?
For example,
add_custom_command(OUTPUT foo_out
COMMAND post_process foo_in > foo_out
DEPENDS foo_in
)
I would like to do
make foo_out
and it will make foo_out. However, if I do this, I get
make: **** No rule to make target `foo_out`. Stop.
and sure enough, the word "foo_out" doesn't exist anywhere in any file in the cmake binary output directory. If I change it to this
add_custom_target(bar DEPENDS foo_out)
add_custom_command(OUTPUT foo_out COMMAND post_process foo_in > foo_out)
Then I can do
make bar
and I can do
make foo_in
but I still can't do
make foo_out
The problem with make bar is that it is unintuitive, as the actual file output is foo_out not bar.
How do I do this?
In my case, I need to run a special processing step to the standard executable target which inserts optional resources into the ELF file. I would like the ability to have both executables as Makefile targets, so I can build the naked ELF executable as well as the resource-injected ELF executable.
If I was writing a custom Makefile, this is trivial to do!
foo_in: foo.c
$(CC) $< -o $#
foo_out: foo_in
post_process $< > $#
And I can do make foo_in and make foo_out.
add_custom_command does not create a new target. You have to define targets explicitly by add_executable, add_library or add_custom_target in order to make them visible to make.
If you have to fix things up for deployment, you could
1. use the install command (somewhere in your CMakeLists.txt) like this:
install(SCRIPT <dir>/post_install.cmake)
to store commands which are executed only when you run make install in a separate .cmake file. Or if the install target is already reserved for other things or you have more complex stuff going on:
2. manually define a deploy target. Once you got that, you can create a custom post-build command which is only executed when you explicitly run make on your deploy target. This allows you to execute commands through a separate target.
In your CMakeLists.txt this could look like:
cmake_minimum_required(VERSION 3.0)
add_executable("App" <sources>)
# option 1: do deployment stuff only when installing
install(SCRIPT <dir>/post_install.cmake)
# option 2: define a deploy target and add post-build commands
add_custom_target("deploy")
add_custom_command(TARGET "deploy" POST_BUILD <some command>)
Both approaches allow you to separate dev builds from expensive ready-to-deploy builds (if I understand correctly, that's the goal here). I would recommend option 1 since it's just cleaner.
Hope this helps!
Documentation Unclear
CMake's documentation is unclear here. The Makefiles generators of CMake do create the source file make rules in sub Makefiles which are not visible in the main Makefile. In the main Makefile you will find only the PHONY rules for your CMake targets. The only exception I know of is the Ninja
Makefiles generator which puts all build rules into single file.
Translating Post-Processing Steps into CMake
From my experience - if post_process is a script - you should probably think about rewriting your post-processing steps with/inside the CMake scripts, because CMake should know about all the file dependencies and variables used for post-processing (it then will e.g. handle all the necessary re-build or clean-up steps for you).
Here is a simplified/modified version of what I do:
function(my_add_elf _target)
set(_source_list ${ARGN})
add_executable(${_target}_in ${_source_list})
set_target_properties(
${_target}_in
PROPERTIES
POSITION_INDEPENDENT_CODE 0
SUFFIX .elf
)
add_custom_command(
OUTPUT ${_target}_step1.elf
COMMAND some_conversion_cmd $<TARGET_FILE:${_target}_in> > ${_target}_step1.elf
DEPENDS ${_target}_in
)
add_custom_target(
${_target}_step1
DEPENDS
${_target}_step1.elf
)
add_custom_command(
OUTPUT ${_target}_out.elf
COMMAND final_post_process_cmd ${_target}_step1.elf > ${_target}_out.elf
DEPENDS ${_target}_step1
)
add_custom_target(
${_target}_out
DEPENDS
${_target}_out.elf
)
# alias / PHONY target
add_custom_target(${_target} DEPENDS ${_target}_out)
endfunction(my_add_elf)
and then call
my_add_elf(foo foo.c)
It's only an example, but I hope it gives the idea: you could call make foo for the final ELF output, make foo_in or make foo_step1 for one of the other steps. And I think all steps are transparent for the user and CMake.
Can't give your Target the same name as one of the Outputs
When you're trying to give a custom target the same name as one of its outputs e.g. like this:
add_executable(foo_in foo.c)
add_custom_command(
OUTPUT foo_out
COMMAND post_process foo_in > foo_out
DEPENDS foo_in
)
add_custom_target(foo_out DEPENDS foo_out)
You end-up with invalid make files. I've raised an issue about this in the hope that there could be a possible solution by extending CMake itself and got the following reply:
CMake is not intended to produce specific content in a Makefile.
Top-level target names created by add_custom_target are always logical
(i.e. phony) names. It is simply not allowed to have a file of the
same name.
Posible Workarounds
So there are some workarounds, but they all have one or the other disadvantage.
1. Shortest Version:
macro(my_add_elf_we _target)
add_executable(${_target}_in ${ARGN})
add_custom_target(
${_target}_out
COMMAND post_process $<TARGET_FILE:${_target}_in> > ${_target}_out
DEPENDS ${_target}_in
)
set_property(DIRECTORY APPEND PROPERTY ADDITIONAL_MAKE_CLEAN_FILES ${_target}_out)
endmacro(my_add_elf_we)
You can't declare OUTPUTs in the add_custom_target() itself, but in this case you don't want to (because you don't want to have any naming confusions). But if you don't declare any outputs:
The target will always considered out-of-date
You need to add the "invisible" outputs the clean build rule
2. Force Output Name Version
Here is a version of the above macro that forces target and output names to given values:
macro(my_add_elf_in_out _target_in _target_out)
add_executable(${_target_in} ${ARGN})
set_target_properties(
${_target_in}
PROPERTIES
SUFFIX ""
OUTPUT_NAME "${_target_in}"
)
add_custom_target(
${_target_out}
COMMAND post_process ${_target_in} > ${_target_out}
DEPENDS ${_target_in}
)
set_property(DIRECTORY APPEND PROPERTY ADDITIONAL_MAKE_CLEAN_FILES ${_target_out})
endmacro(my_add_elf_in_out)
You call it with:
my_add_elf_in_out(foo_in.elf foo_out.elf foo.c)
3. Object Libary Version
The following version uses object libraries, but the system will not reuse the foo_in target linkage:
macro(my_add_elf_obj_in_out _target_in _target_out)
add_library(${_target_in}_obj OBJECT ${ARGN})
add_executable(${_target_in} $<TARGET_OBJECTS:${_target_in}_obj>)
set_target_properties(
${_target_in}
PROPERTIES
SUFFIX ""
OUTPUT_NAME "${_target_in}"
)
add_executable(${_target_out} $<TARGET_OBJECTS:${_target_in}_obj>)
set_target_properties(
${_target_out}
PROPERTIES
SUFFIX ""
OUTPUT_NAME "${_target_out}"
EXCLUDE_FROM_ALL 1
)
add_custom_command(
TARGET ${_target_out}
POST_BUILD
COMMAND post_process ${_target_in} > ${_target_out}
)
endmacro(my_add_elf_obj_in_out)
4. Last and Final Version
And one final version that definitely works only for with Makefile generators and that got me posting the issue at CMake's bug tracker:
macro(my_add_elf_ext_in_out _target_in _target_out)
add_executable(${_target_in} ${ARGN})
set_target_properties(
${_target_in}
PROPERTIES
SUFFIX ""
OUTPUT_NAME "${_target_in}"
)
add_executable(${_target_out} NotExisting.c)
set_source_files_properties(
NotExisting.c
PROPERTIES
GENERATED 1
HEADER_FILE_ONLY 1
)
set_target_properties(
${_target_out}
PROPERTIES
SUFFIX ""
OUTPUT_NAME "${_target_out}"
RULE_LAUNCH_LINK "# "
)
add_custom_command(
TARGET ${_target_out}
POST_BUILD
COMMAND post_process ${_target_in} > ${_target_out}
)
add_dependencies(${_target_out} ${_target_in})
endmacro(my_add_elf_ext_in_out)
Some references
CMake add_custom_command/_target in different directories for cross-compilation
CMake: how do i depend on output from a custom target?
cmake add_custom_command
How do I use CMake to build LaTeX documents?
Turning around the dependencies, and using the second signature of add_custom_command, this should work:
add_custom_target(foo_out DEPENDS foo_in)
add_custom_command(TARGET foo_out POST_BUILD COMMAND post_process foo_in > foo_out)
Note: Adding BYPRODUCTS foo_out will cause (for example) ninja to say
multiple rules generate foo_out. builds involving this target will not be correct; continuing anyway
I'm trying to make CMake generate source files with ANTLR without any success.
Here command I'm using to generate these files:
$ antlr grammar/MyGrammar.g -fo src/parser
My executable target is defined in PROJECT/src/CMakeLists.txt, instead of PROJECT/CMakeLists.txt.
If you're saying you want to execute this command from within PROJECT/src/CMakeLists.txt, then the following should work:
execute_process(COMMAND antlr grammar/MyGrammar.g -fo src/parser
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/..)
Edit
Going by your comment, it looks like you want to invoke this every time you build your executable.
To tie the antlr invocation with your executable, you can use add_custom_command
add_custom_command(TARGET MyExe PRE_BUILD
COMMAND antlr grammar/MyGrammar.g -fo src/parser
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/..)
This will only execute the antlr call if the MyExe target is out of date. If MyGrammar.g is changed, but MyExe doesn't need rebuilt, antlr doesn't run.
If you have multiple targets which depend on antlr being run, or you want to be able to invoke the antlr command any time, you could instead use add_custom_target. This adds the antlr command as a new psuedo-target. If you just build this target, all it does is invoke antlr. For each target which depends on it, use add_dependencies:
add_custom_target(Antlr
COMMAND antlr grammar/MyGrammar.g -fo src/parser
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/..
SOURCES ../grammar/MyGrammar.g)
add_dependencies(MyExe Antlr)
add_dependencies(MyOtherExe Antlr)
As before, antlr will only be invoked if one of the dependent targets needs rebuilt, or if you explicitly build the new custom target "Antlr". (You don't need the SOURCES argument in the add_custom_target call, but this convenience feature adds MyGrammar.g to the target's files visible in IDEs like MSVC)
A little bit off topic but maybe it will be usefull for you.
Here you'll find CMake build file for the ANTLR C runtimme library.
Generated sources are same as any other sources generated from metadata.
You can use QT's UIC complier macro as an example:
MACRO (QT4_WRAP_UI outfiles )
QT4_EXTRACT_OPTIONS(ui_files ui_options ${ARGN})
FOREACH (it ${ui_files})
GET_FILENAME_COMPONENT(outfile ${it} NAME_WE)
GET_FILENAME_COMPONENT(infile ${it} ABSOLUTE)
SET(outfile ${CMAKE_CURRENT_BINARY_DIR}/ui_${outfile}.h)
ADD_CUSTOM_COMMAND(OUTPUT ${outfile}
COMMAND ${QT_UIC_EXECUTABLE}
ARGS ${ui_options} -o ${outfile} ${infile}
MAIN_DEPENDENCY ${infile} VERBATIM)
SET(${outfiles} ${${outfiles}} ${outfile})
ENDFOREACH (it)
ENDMACRO (QT4_WRAP_UI)