I have a problem modifying existing CMake based build-system. All I want to do is add different build rule for some of .c files. For the sake of this problem, I will focus on only one file.
The simplified directories tree looks like this
Project:
./src
- file_of_interest.c
- CmakeFiles.txt
other_files.c
CmakeFiles.txt
So in order to compile file_of_interest.c in a different way I do:
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/file_of_interest.s
COMMAND xt-xcc -S ${CMAKE_CURRENT_SOURCE_DIR}/file_of_interest.c
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/file.c
COMMENT "Generating file_of_interest.s"
)
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/file_of_interest.c.o
COMMAND xt-xcc ${CMAKE_CURRENT_BINARY_DIR}/file_of_interest.s -o file_of_interest.c.o -c
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/file_of_interest.s
COMMENT "Generating file_of_interest.c.o"
)
message(" ${CMAKE_CURRENT_BINARY_DIR} \n ${CMAKE_CURRENT_SOURCE_DIR}")
target_sources(target_name PRIVATE ${CMAKE_CURRENT_BINARY_DIR}/file_of_interest.c.o)
As you can see I used CMake's message() to print paths to be sure all is set up properly. It should work, but it doesn't! I expect CMake to register file_of_interest.c.o as source of target_name (and this is probably working), then "tie" it with my custom command which produces OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/file_of_interest.c.o and then to tie again ${CMAKE_CURRENT_BINARY_DIR}/file_of_interest.c.o with OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/file_of_interest.s and this certainly doesn't happen as CMake shows error message saying CMake Error at CMakeLists.txt:170 (add_executable): Cannot find source file: path/file_of_interest.c.o
The path is OK. So the question is why does CMake cannot recognize recipes for that file?
It seems that you create an executable (call add_executable) in the top-level CMakeLists.txt, but add_custom_command are called from the subdirectory (src/CMakeLists.txt).
This doesn't work: when CMake processes add_executable and searches for the commands generating its sources, it sees only add_custom_commands created in the same CMakeLists.txt.
From the add_custom_command documentation:
A target created in the same directory (CMakeLists.txt file) that specifies any output of the custom command as a source file is given a rule to generate the file using the command at build time.
It is unrelated that target_sources is called from the same directory as add_custom_command: the target is created by add_executable command, and target_sources just modifies its properties.
Related
i'm working on a project requiring cmake. i'd like to add some custom rules to my makefile, but can't quite get my head around how to do it.
both c source files and header files are in the same directory. also in this same directory are a number of .def files, which are the sources for some of the header files #included in the source during compilation.
if i were to do this in a makefile, i'd use a simple rule like
.SUFFIXES: .def
.def.h:
$(PREPROC) $< > $#
how can i do this with cmake ??
i've tried various permutations of the following, both with and without cmake working directory specifications :
add_custom_command(
OUTPUT vvr_const.h
PRE_BUILD
COMMAND preproc vvr_const.def > vvr_const.h
DEPENDS vvr_const.def
)
add_custom_target(vvr_const.h DEPENDS vvr_const.def)
but the header file isn't generated by the time the c source file is compiled, so the compile fails. i've also tried a variation where i replace the last line above with
set_property(SOURCE main.c APPEND PROPERTY OBJECT_DEPENDS vvr_const.h)
in this case, the header file is correctly generated in advance, but make can't find it, and complains that there's no rule to make the target .h.
ideally this would be a general rule, like the make rule above, but i'm not opposed to making a separate rule for each of the .def files if that's what it takes.
cheers.
There are 2 problems with the add_custom_command approach you present:
You did not specify a working directory; by default the command is run in the build directory, not in the source directory.
You rely on shell functionality here (the redirect to a file). Even though this probably still works. You should go with an approach that does not rely on the shell.
To solve issues 1 and 2 I recommend creating a seperate cmake script file receiving the absolute paths to input and output files and using those in the custom command. This allows you to use execute_process to specify the file to write without relying on the platform.
preprocess_def.cmake
# preprocess def file
# parameters INPUT_FILE and OUTPUT_FILE denote the file to use as source
# and the file to write the results to respectively
# use preproc tool to get data to write to the output file
execute_process(COMMAND preproc "${INPUT_FILE}"
RESULT_VARIABLE _EXIT_CODE
OUTPUT_FILE "${OUTPUT_FILE}")
if (_EXIT_CODE)
message(FATAL_ERROR "An error occured when preprocessing the file ${INPUT_FILE}")
endif()
CMakeLists.txt
set(_INPUT_FILE "${CMAKE_CURRENT_SOURCE_DIR}/vvr_const.def")
set(_OUTPUT_FILE "${CMAKE_CURRENT_SOURCE_DIR}/vvr_const.h")
# not necessary to use build event here, if we mark the output file as generated
add_custom_command(OUTPUT "${_OUTPUT_FILE}"
COMMAND "${CMAKE_BUILD_TOOL}" -D "OUPUT_FILE=${_OUTPUT_FILE}" -D "INPUT_FILE=${_INPUT_FILE}" -P "${CMAKE_CURRENT_SOURCE_DIR}/preprocess_def.cmake"
DEPENDS "${_INPUT_FILE}")
add_executable(my_target vvr_const.h ...)
set_source_files_properties(vvr_const.h PROPERTIES GENERATED 1)
Documentation from cmake:
PRE_BUILD
On Visual Studio Generators, run before any other rules are executed within the target. On other generators, run just before PRE_LINK commands.
So possibly your command is just running too late.
I have a cross-platform (Windows, Mac, iOS) CMake project that needs to copy binary resources (images, audio, text files, etc.) to the final application. I previously just added every resource to the add_executable command, and that worked fine until I wanted to organize everything into sub-directories.
To copy application assets while keeping the folder structure I ended up using the following custom command in the windows target:
add_custom_command(
TARGET ${APP_TARGET_NAME} PRE_LINK
COMMAND ${CMAKE_COMMAND} -E copy_directory
${CMAKE_CURRENT_SOURCE_DIR}/${APP_ASSETS_DIR}
$<TARGET_FILE_DIR:${APP_TARGET_NAME}>/assets
)
Which works quite well. The problem comes when I try to do the same thing on macOS. When I use the same $<TARGET_FILE_DIR> trick on macOS I get the address of the output application bundle (which is very good), so I add a /resources to the end of that and try to copy there, but this fails.
In XCode I get the following error:
PhaseScriptExecution CMake\ PreLink\ Rules /Users/someuser/Documents/Build/Test/Test.build/Debug/Test_MAC.build/Script-2CF8724D08BC49E4A13B9E75.sh
cd /Users/someuser/Documents/GitHub/Test
/bin/sh -c /Users/someuser/Documents/Build/Test/Test.build/Debug/Test_MAC.build/Script-2CF8724D08BC49E4A13B9E75.sh
/Users/someuser/Documents/Build/Test/Debug/Test_MAC.app/Contents/MacOS/Test_MAC -E copy_directory /Users/someuser/Documents/GitHub/Test/assets /Users/someuser/Documents/Build/Test/Debug/Test_MAC.app/Contents/Resources
make: *** [Test_MAC_buildpart_0] Segmentation fault: 11
Command /bin/sh failed with exit code 2
Which isn't particularly helpful. I've tried PRE_LINK and POST_BUILD as well as copy_directory and copy.
Why is this failing? I haven't been able to test on iOS, but I imagine that the two would work in a similar way.
How can I copy my assets to the bundle on macOS (also iOS)?
There's not much helpful documentation for framework/bundle generation with CMake on the net. Most wisdom is hidden in CMakeLists.txt files and not in CMake tutorials.
Both methods are known to work, but are a bit tricky to get right. I used them both together on a versioned framework project with CMake's Unix Makefiles generator.
First you add resources to your framework/bundle (mine has the same name as the project, therefore I use ${PROJECT_NAME} throughout the following lines) either by adding them as arguments to add_library, e.g.
add_library(${PROJECT_NAME} SHARED ${SOURCES} ${HEADERS} ${RESOURCES})
Then set your target properties for a framework/bundle:
if(BUILD_MAC_FRAMEWORK)
# Set the framework target properties just to make sure the relevant links inside the framework
# are created. Because the default framework name differs from the project name we change the
# output name property.
set_target_properties(${PROJECT_NAME} PROPERTIES
FRAMEWORK TRUE
FRAMEWORK_VERSION ${MAC_FRAMEWORK_VERSION}
#PUBLIC_HEADER "${PUBLIC_HEADERS}" # does not work recursively
#PRIVATE_HEADER "${PRIVATE_HEADERS}" # does not work recursively
RESOURCE "${CMAKE_BINARY_DIR}/version.plist" # does not work recursively
MACOSX_FRAMEWORK_IDENTIFIER org.company.sampleFramework.framework
MACOSX_FRAMEWORK_SHORT_VERSION_STRING ${PROJECT_VERSION}
MACOSX_FRAMEWORK_BUNDLE_VERSION ${PROJECT_VERSION}
MACOSX_FRAMEWORK_INFO_PLIST "${CMAKE_BINARY_DIR}/Info.plist"
OUTPUT_NAME ${MAC_FRAMEWORK_NAME}
)
endif()
Later set the framework path for the resource files with respect to Resources directory with a helper function
# determine which subdirectory this file (header, resource) should be installed into.
function(set_macosx_properties _removable_prefixes _install_prefix _source_files)
foreach(_file ${_source_files})
get_filename_component(_loc "${_file}" DIRECTORY)
foreach(_prefix ${_removable_prefixes})
string(REPLACE "${_prefix}" "" _loc "${_loc}")
endforeach()
set_source_files_properties(${_file} PROPERTIES MACOSX_PACKAGE_LOCATION ${_install_prefix}${_loc})
endforeach()
endfunction()
set_macosx_properties("${CMAKE_SOURCE_DIR}/include;${CMAKE_BINARY_DIR}/include" "Headers" "${HEADERS}")
set_macosx_properties("${CMAKE_SOURCE_DIR}/data;${CMAKE_BINARY_DIR}/data" "Resources" "${RESOURCES}")
The helper function removes the specified prefixes and replaces them with an installation prefix.
Make sure both commands (add_library and set_macosx_properties) are called from the same directory/CMakeLists.txt! Different locations for the commands do not work.
Or you use a call to add_custom_command as follows. I do not remember if other type of targets did not work, but I have always used POST_BUILD custom targets.
add_custom_command(TARGET ${PROJECT_NAME} POST_BUILD
COMMAND ${CMAKE_COMMAND} -E make_directory $<TARGET_FILE_DIR:${PROJECT_NAME}>/Documentation
COMMAND ${CMAKE_COMMAND} -E create_symlink ./Versions/Current/Documentation $<TARGET_FILE_DIR:${PROJECT_NAME}>/../../Documentation
COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_BINARY_DIR}/html $<TARGET_FILE_DIR:${PROJECT_NAME}>/Documentation/html)
add_custom_command(TARGET ${PROJECT_NAME} POST_BUILD
COMMAND ${CMAKE_COMMAND} -E remove $<TARGET_FILE_DIR:${PROJECT_NAME}>/Documentation/html/${PROJECT_NAME}-${PROJECT_VERSION_MAJOR}.qch
COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_BINARY_DIR}/html/${PROJECT_NAME}-${PROJECT_VERSION_MAJOR}.qch $<TARGET_FILE_DIR:${PROJECT_NAME}>/Documentation)
Finally, installation is done by single command:
install(TARGETS ${PROJECT_NAME} FRAMEWORK DESTINATION . COMPONENT development)
Is there a way to get rid of the CMake Rules folders in targets in Visual Studio?
In this case the game target uses cotire for precompiled header support and the omg target has a custom command that parses the .mix file and outputs the ..._gen.h file.
Also would it be possible to remove the CMakeLists.txt file from there too? I know it's there for convenience but in my workflow it isn't that useful.
EDIT: Started a second bounty because I really need this - these "CMake Rules" folders are bloating my solution explorer because I have 100+ projects which all have them!
I would accept anything - a CMake way, a VS way (some "solution explorer view" or macro or whatever)...
EDIT 2:
here is sort-of the cmake for the omg target:
add_library(omg SHARED D:/omg.cpp D:/omg.mix)
add_custom_command(OUTPUT D:/omg_gen.h MAIN_DEPENDENCY D:/omg.mix COMMAND python D:/mixify.py D:/omg.mix D:/omg_gen.h)
add_custom_target(${target}_gen_${mix_name_only} DEPENDS ${gen_header})
add_dependencies(omg omg_gen)
target_sources(omg PUBLIC D:/omg_gen.h)
so omg_gen.h is generated from omg.mix and then included in omg.cpp
The .rule files are needed by CMake to attach the custom commands to some "dummy" self-generated file, if there are no input files given. You can see this when you look at the .rule file properties of your Visual Studio project in question (see Custom Build Tool/General/Command Line).
If you're not changing the CMake script code containing those target, you can't get rid of them.
You can only move them into the project's root source folder or any other folder you specify.
I've successfully tested the following example:
cmake_minimum_required(VERSION 2.8)
project(NoRulesSourceGroup NONE)
# Overwrite the rule for "CMake Rules" with do-not-match-anything (-> root)
source_group("CMake Rules" REGULAR_EXPRESSION "^$")
# Move ".rule" files somewhere else
source_group("Some Other Source Group" REGULAR_EXPRESSION "\\.rule$")
add_custom_target(
${PROJECT_NAME}
COMMAND ${CMAKE_COMMAND} -E echo "Hello World"
)
Edit: You could also combine the above regular expression with a match for CMakeLists.txt:
source_group("Some Other Source Group" REGULAR_EXPRESSION "CMakeLists\\.txt|\\.rule$")
Edit: If you can modify your CMake script code, you should add to your add_custom_command() call:
MAIN_DEPENDENCY
Specify the primary input source file to the command. This is treated just like any value given to the DEPENDS option but also suggests to Visual Studio generators where to hang the custom command. At most one custom command may specify a given source file as its main dependency.
In your case you won't even need the additional custom target since you have a dependency through the header file. I've successfully tested the following derived from your question's example:
file(WRITE omg.cpp "")
file(WRITE omg.mix "")
add_library(omg SHARED omg.cpp omg.mix)
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/omg_gen.h
MAIN_DEPENDENCY omg.mix
COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/omg.mix ${CMAKE_CURRENT_BINARY_DIR}/omg_gen.h
)
target_sources(omg PUBLIC ${CMAKE_CURRENT_BINARY_DIR}/omg_gen.h)
References
source_group()
Source/cmMakefile.cxx
I am very new to Cmake and need to generate some files at compile time. once generated i need to compile and link the files. I ve created the cmake makefile to compile the already generated files like
cmake_minimum_required(VERSION 2.6)
project(demo)
set(CMAKE_CXX_FLAGS "-DWITH_COOKIES")
add_library(soapC soapC.cpp soapVimBindingProxy.cpp)
add_library(stdsoap2 /home/abdullah/installs/gsoap-shah_edits/gsoap/stdsoap2.cpp)
add_executable(demo test_file.cc test_app.cc)
target_link_libraries(demo soapC stdsoap2 gsoap++)
This successfully compiles the project. However the files soapC.cpp soapVimBindingProxy.cpp needs to be generated first. And I want to generate these files at runtime using the gsoap tool.
following is the command that needs to be run to generate the header file
wsdl2h -o outfile.h infile.wsdl
This takes an input wsdl file and creates a corresponding outfile.h.
Now I tried doing this in cmake like this
cmake_minimum_required(VERSION 2.6)
add_custom_command(
OUTPUT vsphere.h
COMMAND wsdl2h -o vsphere.h vim25/vim.wsdl
)
But something goes wrong here. No error pops up but no file is created either. Am I missing something ? All help much appreciated.
Thanks.
You've just created a command for producing your header file, so CMake knows just where to get vsphere.h from. I'd recommend using OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/vsphere.h in the add_custom_command() call.
Now you need to create a target:
add_custom_target(vsphere_header ALL DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/vsphere.h)
Finally, make your soapC target depend on it:
add_dependencies(soapC vsphere_header)
Be sure to place add_dependencies() call after soapC target definition.
Thanks arrododger and TobyHijzen for your lighting on this issue.
I use add_custom_command with main_dependency feature for solution for this issue. Following is my CMakeLists.txt for famous calc example of gsoap tutorial.
cmake_minimum_required(VERSION 2.8)
# Proejct name
PROJECT(Calculator)
# Make verbose level on/off
SET(CMAKE_VERBOSE_MAKEFILE ON)
# Varialbes used in cmake
SET(TARGET calc_client)
SET(GSOAP_STATIC_LIB gsoap)
SET(CLIENT_SRC calc_client.c)
SET(WSDL2H_EXEC wsdl2h)
SET(WSDL2H_IN http://www.genivia.com/calc.wsdl)
#SET(WSDL2H_IN calc.wsdl)
SET(WSDL2H_OUT calc.h)
SET(WSDL2H_OPT -c -o)
# command for generating stub and xml serializer code
ADD_CUSTOM_COMMAND(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${WSDL2H_OUT}
COMMAND ${WSDL2H_EXEC} -c -ttypemap.dat -o ${WSDL2H_OUT} ${WSDL2H_IN}
COMMENT "=================== Generating ${WSDL2H_OUT} gSOAP Header file ..."
)
SET(SOAPCPP2_EXEC soapcpp2)
SET(STUB soapClient.c soapC.c)
SET(SOAPCPP2_OUT
${STUB}
calc.add.req.xml
calc.add.res.xml
calc.sub.req.xml
calc.sub.res.xml
calc.mul.req.xml
calc.mul.res.xml
calc.div.res.xml
calc.div.req.xml
calc.pow.res.xml
calc.pow.req.xml
calc.nsmap
soapH.c
soapH.h
soapStub.h
soapClientLib.c
)
# command for generating stub and xml serializer code
ADD_CUSTOM_COMMAND(
OUTPUT ${STUB}
COMMAND ${SOAPCPP2_EXEC} -c -C ${WSDL2H_OUT}
MAIN_DEPENDENCY ${WSDL2H_OUT}
COMMENT "=================== Generating ${STUB} outputs ..."
)
# Exutable files and dependents
ADD_EXECUTABLE(${TARGET} ${CLIENT_SRC} ${STUB})
# libraries for taget : for gcc -l option
TARGET_LINK_LIBRARIES(${TARGET} ${GSOAP_STATIC_LIB})
# Compiler options
ADD_DEFINITIONS(-Wall -O2 -s)
The project I'm compiling uses CMake, which loves absolute pathnames.
When I compile with debugging information enabled, gcc puts those long names into .debug_str sections, which is bad for debugging. I'd like to have short relative-to-project-root pathnames there instead.
Is there some option to tell gcc to strip some part of pathname before emitting debug data? Or, maybe, there is some tool that could do that on compiled binaries?
I've tried using SET(CMAKE_USE_RELATIVE_PATHS ON) (which seems to be frowned upon by devs) option, but as I'm using out-of-source builds, pathnames are still not in the form I'd want them to be. I.e. they're ./../src/mod_foo/foo.c instead of mod_foo/foo.c.
You can use the -fdebug-prefix-map flag to remap the debugging information paths. For example, to make the paths relative to the build location use: -fdebug-prefix-map=/full/build/path=.
You can set the RULE_LAUNCH_COMPILE property of a CMake target to have CMake invoke a shell script which transforms the source file path to a project relative path before invoking gcc. Use the CMake function configure_file to generate a shell script which knows about the PROJECT_SOURCE_DIR and PROJECT_BINARY_DIR of your project.
In your outermost CMakeLists.txt add the following code:
configure_file(
"${PROJECT_SOURCE_DIR}/gcc_debug_fix.sh.in"
"${PROJECT_BINARY_DIR}/gcc_debug_fix.sh"
#ONLY)
add_executable (MyExecutable ...)
set_target_properties(MyExecutable PROPERTIES
RULE_LAUNCH_COMPILE "${PROJECT_BINARY_DIR}/gcc_debug_fix.sh")
The following template shell script gcc_debug_fix.sh.in needs to go to the root directory of the CMake project:
#!/bin/sh
PROJECT_BINARY_DIR="#PROJECT_BINARY_DIR#"
PROJECT_SOURCE_DIR="#PROJECT_SOURCE_DIR#"
# shell script invoked with the following arguments
# $(CXX) $(CXX_DEFINES) $(CXX_FLAGS) -o OBJECT_FILE -c SOURCE_FILE
# extract parameters
SOURCE_FILE="${#: -1:1}"
OBJECT_FILE="${#: -3:1}"
COMPILER_AND_FLAGS=${#:1:$#-4}
# make source file path relative to project source dir
SOURCE_FILE_RELATIVE="${SOURCE_FILE:${#PROJECT_SOURCE_DIR} + 1}"
# make object file path absolute
OBJECT_FILE_ABSOLUTE="$PROJECT_BINARY_DIR/$OBJECT_FILE"
cd "$PROJECT_SOURCE_DIR"
# invoke compiler
exec $COMPILER_AND_FLAGS -c "${SOURCE_FILE_RELATIVE}" -o "${OBJECT_FILE_ABSOLUTE}"
The shell script uses the information from the variables PROJECT_BINARY_DIR and PROJECT_SOURCE_DIR to transform the path of the source file to a path relative to the project root and the object file's path to an absolute path. Because gcc gets passed a project relative path now, .debug_str should use that path, too.
The following caveats apply:
Be sure to set the executable bit of gcc_debug_fix.sh.in.
For the script to work CMAKE_USE_RELATIVE_PATHS has to set to OFF again.
The script makes assumptions about the location of the file paths on the command line. This may not work if CMake uses a different rule to invoke the compiler. A more robust solution would be to scan the script arguments for the -o and -c flags.
If I really couldn't fix the make file/tool to do this properly, I would write a wrapper script for gcc that recognises absolute pathnames and converts then to relative ones.
It might look something like this in bash:
#!/bin/bash
out=()
for arg; do
out=("${out[#]}" $(echo "$arg" | sed 's:/my/absolute/directory/:../:'))
done
exec gcc "${out[#]}"
If your source directory has subdirectories then you'll need to handle those carefully, but the above should work for a flat source directory. I've not tested it though, and I wouldn't be surprised if I've got the quoting wrong, but that'll only be a problem if you have pathnames with spaces in. It also doesn't handle parameters like -I/whatever/include, but you can fix that.