CMake - Alternative to generator expression for build output directory? - build

I have a cmake build system gone wild. Before supporting IDEs, everything was ok.
I need to copy files (shaders in this case) to the build directory. They need to be copied when they've changed, regardless of whether the main target is built or not.
I had success before, as I could add a custom command with ${CMAKE_CURRENT_BINARY_DIR}, add dependencies later and everything was fine.
The problem is, when using a generator expression for the command output, it creates a dependency from my custom command to the main target. This means adding a dependency backwards (which is needed to trigger the copy) throws an error because of cyclic dependencies.
This is what I have so far, which doesn't work because the custom target (thus custom command) is not triggered when the main target doesn't need rebuilding.
set(SHADER_IN_DIR ${CMAKE_CURRENT_SOURCE_DIR}/src/shaders)
file(GLOB_RECURSE SHADERS "${SHADER_IN_DIR}/*.glsl")
add_custom_command(TARGET ${PROJECT_NAME} PRE_BUILD
COMMAND ${CMAKE_COMMAND} -E make_directory $<TARGET_FILE_DIR:${PROJECT_NAME}>/shaders/)
set(STAMP_DIR ${CMAKE_CURRENT_BINARY_DIR}/.stamps)
add_custom_command(TARGET ${PROJECT_NAME} PRE_BUILD
COMMAND ${CMAKE_COMMAND} -E make_directory ${STAMP_DIR})
set(STAMP_FILES "")
foreach(SHADER ${SHADERS})
get_filename_component(SHADER_FILENAME ${SHADER} NAME)
set(STAMP_FILE ${STAMP_DIR}/${SHADER_FILENAME}.stamp)
add_custom_command(
OUTPUT ${STAMP_FILE}
COMMAND ${CMAKE_COMMAND} -E touch ${STAMP_FILE}
COMMAND ${CMAKE_COMMAND} -E copy_if_different ${SHADER} $<TARGET_FILE_DIR:${PROJECT_NAME}>/shaders/${SHADER_FILENAME}
DEPENDS ${SHADER}
)
list(APPEND STAMP_FILES ${STAMP_FILE})
endforeach()
add_custom_target(Shaders
SOURCES ${SHADERS}
DEPENDS ${STAMP_FILES})
# Need to add dependency here! But I can't :(
So, is there any other way to get what output directory will be used in an IDE? All "solutions" I've read to force building a target have failed (they pretty much all rely on add_dependencies).
Thank you for saving my sanity.

In the end, instead of trying to find out where the IDE is going to output the binary, I forced output in a predictable bin/ dir.
set(BINARY_OUT_DIR ${CMAKE_CURRENT_BINARY_DIR}/bin)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${BINARY_OUT_DIR})
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${BINARY_OUT_DIR})
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${BINARY_OUT_DIR})
foreach(OUTPUTCONFIG ${CMAKE_CONFIGURATION_TYPES})
string(TOUPPER ${OUTPUTCONFIG} OUTPUTCONFIG)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_${OUTPUTCONFIG} ${BINARY_OUT_DIR})
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY_${OUTPUTCONFIG} ${BINARY_OUT_DIR})
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY_${OUTPUTCONFIG} ${BINARY_OUT_DIR})
endforeach(OUTPUTCONFIG CMAKE_CONFIGURATION_TYPES)

Related

How do file paths and including files/directories with CMake work? [duplicate]

Copying directory from source tree to binary tree. For example: How to copy www to bin folder.
work
├─bin
└─src
├─doing
│ └─www
├─include
└─lib
Thanks.
Since version 2.8, the file command has a COPY sub-command:
file(COPY yourDir DESTINATION yourDestination)
Note that:
Relative input paths are evaluated with respect to the current source
directory, and a relative destination is evaluated with respect to the
current build directory
With CMake 2.8 or later, use the file(COPY ...) command.
With CMake versions below 2.8, the following macro copies files from one directory to another. If you don't want to substitute variables in the copied files, then change the configure_file #ONLY argument (for example to COPYONLY).
# Copy files from source directory to destination directory, substituting any
# variables. Create destination directory if it does not exist.
macro(configure_files srcDir destDir)
message(STATUS "Configuring directory ${destDir}")
make_directory(${destDir})
file(GLOB templateFiles RELATIVE ${srcDir} "${srcDir}/*")
foreach(templateFile ${templateFiles})
set(srcTemplatePath ${srcDir}/${templateFile})
if(NOT IS_DIRECTORY ${srcTemplatePath})
message(STATUS "Configuring file ${templateFile}")
configure_file(
${srcTemplatePath}
${destDir}/${templateFile}
#ONLY)
endif(NOT IS_DIRECTORY ${srcTemplatePath})
endforeach(templateFile)
endmacro(configure_files)
As nobody has mentioned cmake -E copy_directory as a custom target, here's what I've used:
add_custom_target(copy-runtime-files ALL
COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_SOURCE_DIR}/runtime-files-dir ${CMAKE_BINARY_DIR}/runtime-files-dir
DEPENDS ${MY_TARGET})
The configure command will only copy files when cmake is run. Another option is to create a new target, and use the custom_command option. Here's one that I use (if you run it more than once, you'll have to modify the add_custom_target line to make it unique for each call).
macro(copy_files GLOBPAT DESTINATION)
file(GLOB COPY_FILES
RELATIVE ${CMAKE_CURRENT_SOURCE_DIR}
${GLOBPAT})
add_custom_target(copy ALL
COMMENT "Copying files: ${GLOBPAT}")
foreach(FILENAME ${COPY_FILES})
set(SRC "${CMAKE_CURRENT_SOURCE_DIR}/${FILENAME}")
set(DST "${DESTINATION}/${FILENAME}")
add_custom_command(
TARGET copy
COMMAND ${CMAKE_COMMAND} -E copy ${SRC} ${DST}
)
endforeach(FILENAME)
endmacro(copy_files)
Use execute_process and call cmake -E. If you want a deep copy, you can use the copy_directory command. Even better, you could create a symlink (if your platform supports it) with the create_symlink command. The latter can be achieved like this:
execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink ${CMAKE_SOURCE_DIR}/path/to/www
${CMAKE_BINARY_DIR}/path/to/www)
From: http://www.cmake.org/pipermail/cmake/2009-March/028299.html
Thank! That is really helpful advice to use bunch of add_custom_target and add_custom_command. I wrote the following function to use everywhere in my projects. Is also specifies the installation rule. I use it primarily to export interface header files.
#
# export file: copy it to the build tree on every build invocation and add rule for installation
#
function (cm_export_file FILE DEST)
if (NOT TARGET export-files)
add_custom_target(export-files ALL COMMENT "Exporting files into build tree")
endif (NOT TARGET export-files)
get_filename_component(FILENAME "${FILE}" NAME)
add_custom_command(TARGET export-files COMMAND ${CMAKE_COMMAND} -E copy_if_different "${CMAKE_CURRENT_SOURCE_DIR}/${FILE}" "${CMAKE_CURRENT_BINARY_DIR}/${DEST}/${FILENAME}")
install(FILES "${FILE}" DESTINATION "${DEST}")
endfunction (cm_export_file)
Usage looks like this:
cm_export_file("API/someHeader0.hpp" "include/API/")
cm_export_file("API/someHeader1.hpp" "include/API/")
Based on the answer from Seth Johnson; wrote for more convenience:
# Copy files
macro(resource_files files)
foreach(file ${files})
message(STATUS "Copying resource ${file}")
file(COPY ${file} DESTINATION ${Work_Directory})
endforeach()
endmacro()
# Copy directories
macro(resource_dirs dirs)
foreach(dir ${dirs})
# Replace / at the end of the path (copy dir content VS copy dir)
string(REGEX REPLACE "/+$" "" dirclean "${dir}")
message(STATUS "Copying resource ${dirclean}")
file(COPY ${dirclean} DESTINATION ${Work_Directory})
endforeach()
endmacro()

FLEX/BISON generate location.hh, position.hh, stack.hh in different folder

I have folder structure like this
include/
src/
| parser.yy
| scanner.ll
and in the src/CMakeLists.txt:
SET(BisonOutput ${CMAKE_SOURCE_DIR}/src/_parser.cpp)
IF(BISON_FOUND)
ADD_CUSTOM_COMMAND(
OUTPUT ${BisonOutput}
COMMAND ${BISON_EXECUTABLE}
--defines=${CMAKE_SOURCE_DIR}/include/_parser.hpp
--output=${BisonOutput}
${CMAKE_SOURCE_DIR}/src/parser.yy
COMMENT "Generating parser"
)
ENDIF()
SET(FlexOutput ${CMAKE_SOURCE_DIR}/src/_scanner.cpp)
IF(FLEX_FOUND)
ADD_CUSTOM_COMMAND(
OUTPUT ${FlexOutput}
COMMAND ${FLEX_EXECUTABLE}
--outfile=${FlexOutput}
${CMAKE_SOURCE_DIR}/src/scanner.ll
COMMENT "Generating scanner"
)
ENDIF()
However the files locations.hh, position.hh and stack.hh are generated inside the src directory. Is it possible to somehow specify that i want these files generated inside the include directory?
I am using Bison 3.0.4 and Flex 2.6.4
I'm not sure if Bison/Flex allows you to generate them in a separate location, but you can use CMake to copy them to the include directory once they are generated. Add another add_custom_command call with PRE_BUILD to ensure they are copied before building your target:
ADD_CUSTOM_COMMAND(
TARGET MyTarget PRE_BUILD
COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_SOURCE_DIR}/src/locations.hh ${CMAKE_SOURCE_DIR}/include
COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_SOURCE_DIR}/src/position.hh ${CMAKE_SOURCE_DIR}/include
COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_SOURCE_DIR}/src/stack.hh ${CMAKE_SOURCE_DIR}/include
)

Cmake: How to have add_custom_command() run after all project files are built

Using Cmake v3.8, I need my custom command to run only after my newly built .hex, .map, and .elf files are produced. However, the command is not truly running after all of the *.hex, *.map, and *.elf files are produced. Here is what I have:
add_custom_command(
POST_BUILD
COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/performCrc32.py
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
OUTPUT performCrc32.out
COMMENT "Running CRC32 check..."
)
add_custom_target(
performCrc32 ALL
DEPENDS performCrc32.py
performCrc32.out
)
What am I missing, if anything?
There is no way for add commands to be executed "after the build is entirely complete".
You may add commands to be executed after specific target is built:
add_custom_command(TARGET <kernel-target> POST_BUILD
COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/performCrc32.py
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
COMMENT "Running CRC32 check..."
)
This would add command to be executed after <kernel-target> and all its dependencies will be built. Note on the absence of OUTPUT option in this case.
This is preferrable way for post-build checks, as a check will be performed every time target is actually (re)built.
You may bind your custom command to your custom target (as usual), and add dependencies for the target:
add_custom_command(
COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/performCrc32.py
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
OUTPUT performCrc32.out
COMMENT "Running CRC32 check..."
)
add_custom_target(
performCrc32 ALL
DEPENDS performCrc32.py
performCrc32.out
)
add_dependencies(performCrc32 <hex-targets...> <map-targets> <elf-target>)
In this case command will be executed after all dependent targets are built. However, the command will be executed only first build: once OUTPUT file will be created, the command won't be executed again.
POST_BUILD option for add_custom_command is applicable only for TARGET flow of this command, as described above. I am curious why CMake doesn't emit error for your case, when you use POST_BUILD without TARGET.

CMake add target for invoking clang analyzer

I'd basically like to achieve the same as http://blog.alexrp.com/2013/09/26/clangs-static-analyzer-and-automake, but with CMake.
analyze_srcs = foo.c
analyze_plists = $(analyze_srcs:%.c=%.plist)
CLEANFILES = $(analyze_plists)
$(analyze_plists): %.plist: %.c
#echo " CCSA " $#
#$(COMPILE) --analyze $< -o $#
analyze: $(analyze_plists)
.PHONY: analyze
So you can run
make analyze
make clean
I guess I need to use add_custom_command/add_custom_target and somehow change the "object file" extension just for that target.
Afterwards get a list of the generated files to perhaps pass them to a script for combining them into 1 output file.
Can anyone point me in the right direction?
You can use scan-build when running cmake.
scan-build cmake /path/to/source
scan-build make
scan-build sets the CC and CXX environment variables which are picked up by cmake.
I found a way:
function(add_clang_static_analysis target)
get_target_property(SRCs ${target} SOURCES)
add_library(${target}_analyze OBJECT EXCLUDE_FROM_ALL ${SRCs})
set_target_properties(${target}_analyze PROPERTIES
COMPILE_OPTIONS "--analyze"
EXCLUDE_FROM_DEFAULT_BUILD true)
endfunction()
Combining clang's plist files (which get extension .o this way) into a report is still open ($<TARGET_OBJECTS:objlibtarget>?).
The following solution has the drawback of compiling and analyzing the entire project, not the specific targets.
set(on_side_build_path ${CMAKE_BINARY_DIR}/clang_static_analysis)
set(scan_build_path scan-build)
set(reports_path ${CMAKE_BINARY_DIR}/clang_static_analysis_reports)
# Creates clean directory where the analysis will be built.
add_custom_target(clang_static_analysis_prepare
COMMAND ${CMAKE_COMMAND} -E rm -rf ${on_side_build_path}
COMMAND ${CMAKE_COMMAND} -E make_directory ${on_side_build_path}
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
)
# Runs the analysis from the path created specifically for that task. Use 'my own' project source directory as the source directory.
add_custom_target(clang_static_analysis
# scan-build wants Debug build, for better analysis.
COMMAND ${scan_build_path} ${CMAKE_COMMAND} ${CMAKE_SOURCE_DIR} -DCMAKE_BUILD_TYPE=Debug
COMMAND ${scan_build_path}
-v -v -o ${reports_path}
${CMAKE_COMMAND} --build .
WORKING_DIRECTORY ${on_side_build_path}
)
# Run the *_prepare target always before the analysis
add_dependencies(clang_static_analysis clang_static_analysis_prepare)
Invoke it with:
cmake --build . --target clang_static_analysis
Bonus #1: Allowing custom toolchains to work
scan-build injects the CC and CXX environment variables to specify the replaced compilers, which are ccc-analyzer and c++-analyzer. When defining CMAKE_C_COMPILER and CMAKE_CXX_COMPILER the CC and CXX variables will be ignored. What you need to do to support scan-build is to point CMAKE_C*_COMPILER variables to use the one from environment, if defined. So having that in your toolchain file:
set(CMAKE_C_COMPILER some/path/to/c_compiler)
set(CMAKE_Cxx_COMPILER some/path/to/cxx_compiler)
Replace it with:
if(DEFINED ENV{CC})
set(CMAKE_C_COMPILER $ENV{CC})
else()
set(CMAKE_C_COMPILER some/path/to/c_compiler)
endif()
if(DEFINED ENV{CXX})
set(CMAKE_CXX_COMPILER $ENV{CXX})
else()
set(CMAKE_CXX_COMPILER some/path/to/cxx_compiler)
endif()
Bonus #2: Using scan-build from the LLVM toolchain
If your custom toolchain is LLVM, then most probably you want to use the scan-build command from the toolchain. To enable it, simply define the path to toolchain path using cmake's cache variables:
set(LLVM_TOOLCHAIN_PATH "some/path/here" CACHE PATH "Path to the LLVM toolchain")
or from the command line:
cmake -DLLVM_TOOLCHAIN_PATH=some/path/here ...
and then reuse the path from the custom target:
set(scan_build_path ${LLVM_TOOLCHAIN_PATH}/bin/scan-build)
Bonus #3: Adding test command
Note: enable_testing shall be called before add_test. enable_testing() must be called from the project's top level CMakeLists.txt for ctest to resolve paths to tests.
add_test(
NAME clang_static_analysis
COMMAND ${CMAKE_COMMAND} --build . --target clang_static_analysis
)
Run it like that:
# Fire configure and generate stages
cmake ../source/dir
ctest -R clang_static_analysis --verbose

CMake ExternalProject_Add() and FindPackage()

Is there are proper way to find a library (via FindPackage()) which was built with ExternalProject_Add()?
The problem is that CMake cannot find the library at CMake-time because the external library gets build at compile time. I know that it is possible to combine these two CMake function when building the library and the project in a superbuild but I want to use it in a normal CMake project.
In fact I would like to build VTK 6 with ExternalProject_Add and find it with FindPackage all inside my CMake project.
there is a way to do this. but it´s kind of hackish.
you basically add a custom target, that reruns cmake during build.
you will have to try this in a small test project, to decide if it works for you
find_package(Beaengine)
############################################
#
# BeaEngine
#
include(ExternalProject)
externalproject_add(BeaEngine
SOURCE_DIR ${PROJECT_SOURCE_DIR}/beaengine
SVN_REPOSITORY http://beaengine.googlecode.com/svn/trunk/
CMAKE_ARGS -DoptHAS_OPTIMIZED=TRUE -DoptHAS_SYMBOLS=FALSE -DoptBUILD_64BIT=FALSE -DoptBUILD_DLL=FALSE -DoptBUILD_LITE=FALSE
INSTALL_COMMAND ""
)
if(NOT ${Beaengine_FOUND})
#rerun cmake in initial build
#will update cmakecache/project files on first build
#so you may have to reload project after first build
add_custom_target(Rescan ${CMAKE_COMMAND} ${CMAKE_SOURCE_DIR} DEPENDS BeaEngine)
else()
#Rescan becomes a dummy target after first build
#this prevents cmake from rebuilding cache/projects on subsequent builds
add_custom_target(Rescan)
endif()
add_executable(testapp testapp.cpp )
add_dependencies(testapp Rescan)
if(${Beaengine_FOUND})
target_link_libraries(testapp ${Beaengine_LIBRARY})
endif()
this seems to work well for mingw makefiles / eclipse makefile projects.
vs will request to reload all projects after first build.
You can force a build using the build_external_project function below.
It works by generating a simple helper project inside the build tree and then calling the cmake configuration and the cmake build on the helper.
Customize at will for the actual ExternalProject_add command.
Note that the trailing arguments are used to pass CMAKE_ARGS. Furthur enhancements are left as an exercise to the reader :-)
# This function is used to force a build on a dependant project at cmake configuration phase.
#
function (build_external_project target prefix url) #FOLLOWING ARGUMENTS are the CMAKE_ARGS of ExternalProject_Add
set(trigger_build_dir ${CMAKE_BINARY_DIR}/force_${target})
#mktemp dir in build tree
file(MAKE_DIRECTORY ${trigger_build_dir} ${trigger_build_dir}/build)
#generate false dependency project
set(CMAKE_LIST_CONTENT "
cmake_minimum_required(VERSION 2.8)
include(ExternalProject)
ExternalProject_add(${target}
PREFIX ${prefix}/${target}
URL ${url}
CMAKE_ARGS ${ARGN}
INSTALL_COMMAND \"\"
)
add_custom_target(trigger_${target})
add_dependencies(trigger_${target} ${target})
")
file(WRITE ${trigger_build_dir}/CMakeLists.txt "${CMAKE_LIST_CONTENT}")
execute_process(COMMAND ${CMAKE_COMMAND} ..
WORKING_DIRECTORY ${trigger_build_dir}/build
)
execute_process(COMMAND ${CMAKE_COMMAND} --build .
WORKING_DIRECTORY ${trigger_build_dir}/build
)
endfunction()
Time has passed and CMake implemented a native version allowing to reference targets from an ExternalProject_Add.
This feature is implemented in the FetchContent module. It allows downloading and immediately consuming targets defined at configure time.
It uses a scratch build dir as hinted by my previous answer, but in a more integrated API.