Suppose I have a directory structure as follows:
/main.cpp
/CMakeLists.txt
/foo/foo.cpp
/foo/CMakeLists.txt
where my /CMakeLists.txt file contains the following:
project(Test)
add_subdirectory("foo")
add_executable(Test main.cpp foo/foo.cpp)
target_link_libraries(Test ${OpenNI_LIB})
and my /foo/CMakeLists.txt file contains the following:
find_library(OpenNI REQUIRED)
When I use the line add_subdirectory("foo") in the first CMakeLists.txt, what actually happens? Does it search for a second CMakeLists.txt file in foo, and add the contents to the first? Will any variables defined the second file be available in the first? And specifically in this example, will the variable ${OpenNI_LIB} be recognised in the first, given that it is defined in the second?
Thanks.
Does it search for a second CMakeLists.txt file in foo
Yes, it does
and add the contents to the first?
No it doesn't. It performs a number of configuring actions such as finding libraries etc and a generates separate Makefile and/or other build-time artifacts.
And specifically in this example, will the variable ${OpenNI_LIB} be recognised in the first, given that it is defined in the second?
no, unless such a construction
find_library(OpenNI REQUIRED) # this sets variables for OpenNI
# in the context of foo/CMakeLists.txt
set(OpenNI_LIB ${OpenNI_LIB} PARENT_SCOPE) # this copies ${OpenNI_LIB}
# into the context of /CMakeLists.txt
is used in foo/CMakeLists.txt
By default variables defined in a subdirectory's CMakeLists.txt are also defined in the subdirectory's subdirectories, that is if foo/ in turn contained bar/ with its own CMakeLists.txt, then within bar/'s CMakeLists.txt ${OpenNI_LIB} would be set.
P.S. message(STATUS "Some message with ${VAR}") in doubtful places of CMakeLists.txt is your friend. Just look into cmake output.
Related
I have a source and build tree that looks something like this:
+-build/
+-bin/
+-modules/
+-src/
+-tests/
+-test1/
+-test2/
I have also configured CMake to write the executables into the build/bindirectory. That all works fine.
What I would like is to have most of my executables written into the build/bin directory, while those built from sources under the test directories be written into a build/bin/tests directory.
Is this possible? Can someone point me in the right direction?
I've tried setting the RUNTIME_OUTPUT_DIRECTORY variable directly and I've tried using set_target_properties, but without success.
Ideally, I like to be able to set something in the CMakeLists.txt file in the tests directory and have it trickle down into the subdirectories.
You may set CMAKE_RUNTIME_OUTPUT_DIRECTORY variable as many times as you want. Each setting will affect only on the executables created since that setting until the next one.
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
# Futher executables will be placed under 'bin/'
add_executable(my_program <sources>...)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin/tests)
# Futher executables will be placed under 'bin/tests/' instead
add_executable(test1 <sources>...)
add_executable(test2 <sources>...)
If you are creating the tests in the separate CMakeLists.txt, the settings can be made modular:
CMakeLists.txt:
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
# Futher executables will be placed under 'bin/'
add_executable(my_program <sources>...)
add_subdirectory(tests)
tests/CMakeLists.txt:
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin/tests)
# Executables created below will be placed under 'bin/tests/' instead
add_executable(test1 <sources>...)
add_executable(test2 <sources>...)
Actually, when you call add_executable, it just uses the current value of the CMAKE_RUNTIME_OUTPUT_DIRECTORY variable. This fact can be found in the documentation about RUNTIME_OUTPUT_DIRECTORY target property, which is affected by the variable.
I'm using the FindProtobuf module in a project where the protocol buffer files are in a sub-directory. I want the CMakeLists.txt file in that sub-directory to invoke protoc to generate the CPP Files. My project folder structure is like this:
cammy/CMakeLists.txt # Root CMakeLists.txt
cammy/protofiles/test.proto # protofile
cammy/protofiles/CMakeLists.txt
I have the include(FindProtobuf), the find_package invocation and the call to PROTOBUF_GENERATE_CPP in the CMakeLists.txt file in protobuf folder.
The executable build step is in the Root CMakeLists.txt file and I add the generated files
to the target executable in this file
ie.
add_executable( ${EXEC} ${SRCS} ${PROTO_SRC} ${PROTO_HEADER} )
target_link_libraries( ${EXEC} ${PROTOBUF_LIBRARIES} )
are both defined in the root CMakeLists.txt
When I run cmake, it does not run protoc to generate the Source files even though I expilicitly tie generated sources to the executable thereby creating a dependency.
When I move all the contents of CMakeLists.txt in the protofiles folder into the root CMakeLists.txt, the proto files are compiled.
Can anyone help me with this? I want all the protocol buffer building stuff to go in the CMakeLists.txt file created in the protofiles folder.
I also noticed that variables generated in the inner CMakeLists.txt ( like PROTO_SRC ) are defined in the inner file when printed ( ie I get the correct generated CPP filename ) but when I print the same variable in the root file.. it is empty. Its almost as though I need to "export" (if there were a way in cmake ) the variables out to the root folder.
Any help would be much appreciated.
Thanks
Kartik
I think [FindProtobuf][0] isn't really meant to be used this way. From its docs:
NOTE: The PROTOBUF_GENERATE_CPP macro & add_executable() or add_library()
calls only work properly within the same directory.
You're trying to use the PROTOBUF_GENERATE_CPP macro in a subdirectory, and although the CMake docs don't really make it clear, a subdirectory introduces a new scope for variables. This means that any variables set or modified in the subdir scope don't affect similarly-named variables in the parent scope. Hence the reason for PROTO_SRC being available in your protofiles dir, but not in the parent.
The way to pass variables up a scope is to use [set(... PARENT_SCOPE)][1], so in protofiles/CMakeLists.txt you could do:
PROTOBUF_GENERATE_CPP(PROTO_SRC PROTO_HEADER test.proto)
set(PROTOBUF_INCLUDE_DIRS ${PROTOBUF_INCLUDE_DIRS} PARENT_SCOPE)
set(PROTOBUF_LIBRARIES ${PROTOBUF_LIBRARIES} PARENT_SCOPE)
set(PROTO_SRC ${PROTO_SRC} PARENT_SCOPE)
set(PROTO_HEADER ${PROTO_HEADER} PARENT_SCOPE)
However, this still doesn't get us all the way!
CMake doesn't actually invoke the protoc compiler to generate the .pb.h and .pb.cc files - it uses [add_custom_command][2] to do this. The custom command specifies the .pb.h and .pb.cc files as outputs, and the custom command is only invoked (i.e. protoc executed) if a subsequent target which depends on these files is built.
So, at configure time (when CMake executes) these files don't exist. This is a problem if you try to add them as sources to an add_library or add_executable command - CMake needs to be told that these files don't exist when it runs, but that they will exist at build time.
The way to do that is to set the [GENERATED][3] property to TRUE for these files. The PROTOBUF_GENERATE_CPP macro does that automatically, but as with the variables, the property isn't populated up into the parent scope. So in your top-level CMakeLists.txt, you also need to add:
set_source_files_properties(${PROTO_SRC} ${PROTO_HEADER} PROPERTIES
GENERATED TRUE)
As you can see, using PROTOBUF_GENERATE_CPP in a different dir to the corresponding add_library/add_executable commands is a bit fragile. If you can avoid doing it, you probably should.
[0]: https://cmake.org/cmake/help/latest/module/FindProtobuf.html "CMake latest documentation for "FindProtobuf" module"
[1]: https://cmake.org/cmake/help/latest/command/set.html "CMake latest documentation for "set" command"
[2]: https://cmake.org/cmake/help/latest/command/add_custom_command.html "CMake latest documentation for "add_custom_command""
[3]: https://cmake.org/cmake/help/latest/prop_sf/GENERATED.html "CMake latest documentation for "GENERATED" source file property"
I'm trying to compile executable files in a subdirectory project/model/tests for testing and need to link my model files which reside at project/model. However, I can't get it to work. I've successfully added the parent directory but cmake keeps telling me no source file found for foo.cpp, which is in the parent directory, while bar.cpp, which is in the current directory, is added correctly.
cmake_minimum_required(VERSION 2.6)
# get parent directory
get_filename_component(MODEL_DIR ${CMAKE_CURRENT_SOURCE_DIR} PATH)
# Locate GTest
find_package(GTest REQUIRED)
# Add parent directory
include_directories(${GTEST_INCLUDE_DIRS} ${MODEL_DIR})
link_directories(${MODEL_DIR})
# all included directories are printed out correctly
get_property(dirs DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} PROPERTY INCLUDE_DIRECTORIES)
foreach(dir ${dirs})
message(STATUS "dir='${dir}'")
endforeach()
# foo.cpp, which is in the parent directory is not found
add_executable(runTests foo.cpp bar.cpp)
target_link_libraries(runTests ${GTEST_LIBRARIES} pthread)
Thank you.
When files listed in add_executable() and add_library() are given as relative paths (which they almost always are), they are interpretedd relative to CMAKE_CURRENT_SOURCE_DIR. In other words, you have to do one of these:
add_executable(runTests ../foo.cpp bar.cpp)
Or:
add_executable(runTests ${MODEL_DIR}/foo.cpp bar.cpp)
Side note: it's almost never a good idea to use link_directories(); that command is genrally more trouble than it's worth. The preferred alternative is to provide full paths to target_link_libraries() where necessary.
The project has roughly the following structure:
include/
lib_name/
public_foo.h
public_bar.h
src/
CMakeLists.txt
foo.c
foo.h
bar.c
bar.h
CMakeLists.txt
The top-level CMakeLists.txt file defines a shared library target
add_library(lib_name SHARED "src/foo.c" "src/bar.c")
At the same time, there's a custom command
add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/src/foo-impl.c" ...)
that generated foo-impl.c in the build directory that is included by `foo.c' like this:
#include <some_header.h>
#include <other.h>
#include "foo-impl.c"
In order to be able to include foo-impl.cI do the following in src/CMakeLists.txt
include_directories("${CMAKE_CURRENT_BINARY_DIR}")
Looks like it should work, right?
Well, it doesn't work - the src directory is not added to compiler flags for foo.c. It seems like include directories affect only targets defined in the same directory (or subdirectories).
I know I can just do
include_directories("${CMAKE_CURRENT_BINARY_DIR}/src")
from the root CMakeLists.txt (in fact, this is how I'm doing it at the moment) but that's not acceptable: every subdirectory will see the parent's files and this can eventually lead to file name collisions.
How do people overcome this in large projects? or maybe I'm doing something wrong?
Like most cmake commands, include_directories only affects targets in that directory and subdirectories. And IIRC only targets defined after the command. That's intentional. It's how you define different flags for different modules.
And when I say like most cmake commands, I really mean most. Most importantly including add_definitions and set except with CACHE argument.
Also remember, that include_directories apples to targets, not files.
Either define the library in the subdirectory (makes most sense to me), put everything in the top-level CMakeLists.txt or set the flags on the target only using set_target_properties(lib_name PROPERTIES COMPILE_FLAGS "-I${CMAKE_BINARY_DIR}/src") (must be done after the target is defined).
I'm writing a cmake file for a project which has the following structure
project/ (root)
libraries/ (contains (precompiled) libraries
src/
code/ (contains a set of fortran files)
My CMakeLists.txt file is currently in project/ and effectively is just
cmake_minimum_required(VERSION 2.6)
enable_language(Fortran)
project(project1)
set(projsrc src/code)
set(libdir lib/)
find_library(PROJ_LIBRARY pr10 PATHS ${libdir})
add_executable (sc1 sc1.f90)
target_link_libraries(sc1 ${PROJ_LIBRARY})
This creates my binary in the same folder as the source code, when I actually want it in the level above (i.e. in the src folder - this structure will be changed so we have a bin folder eventually), but haven't worked out how to do it.
Some answers on SO say you have to have a CMakeLists.txt file in every folder - is this correct? Is it possible to set an environment variable or use a CMake variable (e.g. http://cmake.org/cmake/help/v2.8.8/cmake.html#command:set). It's also not very clear from some answers whether the solutions they have posted are C++ specific (as that is what language CMake most often seems to be used for).
Edit
I found out that I can change it to the behaviour I want by modifying it slightly:
cmake_minimum_required(VERSION 2.6)
enable_language(Fortran)
project(project1)
set(projsrc src/code)
set(libdir lib/)
find_library(PROJ_LIBRARY pr10 PATHS ${libdir})
add_executable (src/sc1 ${projsrc}/sc1.f90)
target_link_libraries(src/sc1 ${PROJ_LIBRARY})
However, this doesn't explain why my behaviour is different to how it should be, according to arrowdodger below. I'm also still trying to work out how to display the values of environment variables; I've tried the following with no luck:
message(${RUNTIME_OUTPUT_DIRECTORY})
message($ENV{RUNTIME_OUTPUT_DIRECTORY})
message(${CMAKE_RUNTIME_OUTPUT_DIRECTORY})
message($ENV{CMAKE_RUNTIME_OUTPUT_DIRECTORY})
By default, binaries will appear in respective subdirectory of your build dir. By respective i mean the directory that contains CMakeLists.txt with add_executable() call.
For example, if you have following CMakeLists.txt
add_executable(tgt1 src1.f90)
add_executable(tgt2 subdir/src2.f90)
in the root folder, you will get both binaries in ${CMAKE_BINARY_DIR}. So if you wish tgt2 to be in ${CMAKE_BINARY_DIR}/subdir, you need to add CMakeLists.txt there and call add_executable(tgt2 src2.f90) from there.
You can change this behavior:
CMAKE_LIBRARY_OUTPUT_DIRECTORY, CMAKE_RUNTIME_OUTPUT_DIRECTORY and others.
You can also set respective target properties.