CMake add_subdirectory() - cmake

Introduction:
I am trying to use CMake to obtain cross platform compilation scripts (for VS 9.0 on a Windows32 and Makefiles for Unix).
I am experiencing something i can't understand about add_subdirectory().
Let me show you my code :
Context:
My architecture for a module named "module1" is something like this :
CMakeLists.txt
include/
file1.h
file2.h
*.h
src/
file1.cpp
file2.cpp
*.cpp
test/
CMakeLists.txt
src/
testfile1.cpp
testfile2.cpp
The architecture of my whole application is composed of these modules which are in themselves projects that could work independantly.
My goals:
I want to compile my module as a library
I want to test the library with the code in the test/ folder
Here are the CMakeLists i wrote :
This one is the CMakeLists.txt in the root directory of my module.
#ENSURE MINIMUM VERSION OF CMAKE
cmake_minimum_required(VERSION 2.8)
#CONFIGURATION OF THE PROJECT
#NAME OF THE PROJECT
project(MyProject)
#OUTPUT OF THE PROJECT
set(LIBRARY_OUTPUT_PATH lib/${CMAKE_BUILD_TYPE})
#ADD THE HEADERS OF THE LIBRARY BEING CREATED
include_directories(include)
#ADD 3rd PARTY OPENCV LIBRARIES
find_package(OpenCV REQUIRED)
#ADD 3rd PARTY XERCES LIBRARIES
include_directories(${XERCES_INCLUDE_DIR})
link_directories(${XERCES_LIB_DIR})
set(Xerces_LIBS xerces-c_3D.lib)
#CONFIGURATION OF THE LIBRARY
file(GLOB_RECURSE MYPROJECT_MODULE_CXX src/*)
file(GLOB_RECURSE MYPROJECT_MODULE_HDR include/*)
#NAME OF THE PRESENT LIBRARY
set(MYPROJECT_MODULE_LIB_NAME myModuleLib)
add_library(${MYPROJECT_MODULE_LIB_NAME}
SHARED
${MYPROJECT_MODULE_CXX}
${MYPROJECT_MODULE_HDR}
)
target_link_libraries(${MYPROJECT_MODULE_LIB_NAME}
${OpenCV_LIBS}
${Xerces_LIBS}
)
#CONTINUE IN THE SUB FOLDERS
add_subdirectory(test)
And then, in the test/ folder, here is the CMakeLists.txt
#ENSURE MINIMUM VERSION OF CMAKE
cmake_minimum_required(VERSION 2.8)
#CONFIGURATION OF THE PROJECT
#NAME OF THE PROJECT
project(MyProjectTest)
#OUTPUT OF THE PROJECT
set(EXECUTABLE_OUTPUT_PATH bin/${CMAKE_BUILD_TYPE})
#ADD OUR TESTED LIBRARY
include_directories(../include)
link_directories(../build/lib/${CMAKE_BUILD_TYPE})
#CONFIGURATION OF THE EXE
file(GLOB_RECURSE MYPROJECT_MODULE_TEST_CXX src/*)
#NAME OF THE PRESENT EXECUTABLE
set(MYPROJECT_MODULE_TEST_BIN_NAME myModuleTest)
add_executable(${MYPROJECT_MODULE_TEST_BIN_NAME}
${MYPROJECT_MODULE_TEST_CXX}
)
target_link_libraries(${MYPROJECT_MODULE_TEST_BIN_NAME}
${MYPROJECT_MODULE_LIB_NAME}
)
Question
The CMake outputs a correct MyProject.sln Visual Studio 9.0 solution, which compiles successfully in my library linked with OpenCV and Xerces (and other 3rd part libraries). However the test binary did not output any MyProjectTest.sln.
I thought, (and read in the CMake documentation) that add_subdirectory(dir) was used to do CMake in the following sub directory (i mean, the name could not be clearer :p !), so shouldn't it continue CMake in the test/ directory and create my MyProjectTest.sln solution ?
I use the GUI CMake to run the root CMakeLists.txt in a build directory that i create in the root of my module. When I explore the build directory that's where I can find my MyProjet.sln, a test/ folder, but no MyProjectTest.sln in it !

This may not solve your original problem but in your test/folder/CMakeLists.txt try changing
#ADD OUR TESTED LIBRARY
include_directories(../include)
link_directories(../build/lib/${CMAKE_BUILD_TYPE})
to
#ADD OUR TESTED LIBRARY
include_directories(${CMAKE_SOURCE_DIR}/include)
link_directories(${CMAKE_BINARY_DIR}/lib/${CMAKE_BUILD_TYPE})
otherwise you are assuming that your build folder is always named build.

After three days trying everything, I finally found the answer... Sir DLRdave was right actually: the problem was not from the code itself but from something "out of the code".
Problem found:
I created and edited all my files with Notepad++. Actually when opening the files with windows notepad (because i was curious) a strange rectangle symbol appeared and the file did not look like the one I usually see on Notepad++
I found out that the symbol was a "\n\r" that Notepad++ did not show me (it must be filtered) but going on windows notepad, you could see that the whole file was "impure" and appeared on a single line instead of the layout i saw on Notepad++.
As this "encoding" bug appeared only in the subdirectory CMakeLists, it could not be read but said no error when interpreting with CMake and that's probably why I had no returned error from running CMake.
Solution:
I used the native2ascii.exe tool from Java to correct the encoding error.
The why:
Actually what it probably means is that the syntaxic parser of CMake has probably not been designed for filtering this type of char appearing with strange encoding, that's why it gave me 3 days of intense debugging.

Related

Build gtest as shared library (dll) in CMake

I have never worked with CMake before, so please forgive any rookie mistakes. Most of the following working frame has been given to me by my project group.
The goal is to build GoogleTest into a .dll, to be used in different, indepentent parts of our project. I'm having troubles setting up CMake the right way.
The work-flow so far has been:
Clone gtest from git --> also downloads a CMake List file
Alter variables in CMakeCache.txt to have it produce a Code::Blocks project file
Compile the project file in Code::Blocks
So far, it produces a static library (.a files) that can be used in our project. I'm having troubles genereating .dll files.
Variables I have tried changing:
BUILD_SHARED_LIBS:BOOL=ON --> the files generated by Code::Blocks now have a .dll.a double extension
CMAKE_C_FLAGS and all the corresponding C++ flags where set to -DGTEST_CREATE_SHARED_LIBRARY=1 as given here
CMAKE_EXE_LINKER_FLAGS has been set to -shared to make the linker produce .dll files
I have worked my way through the GoogleTest documentation here and here but in both, building it into a .dll is merely a 2-sentence-topic.
As #Tsyvarev pointed out, the .dll files were created in a (very) different folder.

Zephyr / PlatformIO / CMake / external code

I'm pretty new to Zephyr and am having trouble adding and compiling code in a sibling folder. This may be further complicated by using PlatformIO, which has a slightly different build structure than the stock Zephyr structure.
The IDE is Visual Studio Code under Windows
The structure of the code is:
Parent Folder
|-ext_library (contains CMakeList.txt)
|--source
|--include
|-zephyr_project (structure generated by PlatformIO)
|--zephyr (contains the master CMakeList.txt and prj.conf)
|--source
|--include
|--lib
What I want to do is add either source files or a static library from ext_library to the zephyr_project with out manually copying source / include files or manually building the library and copying it over.
What I've tried so far:
Adding a path to ext_library in the FILE(GLOB ...) command in the zephyr_project/zephyr/CMakeList.txt. This command pulls the
source files from zephyr_project/source, but doesn't seem to like
either relative or static paths to ext_library.
Adding a CMakeList.txt in the ext_library that compiles a static library. This also requires using add_subdirectory to the
zephyr CMakeLists.txt file. This didn't seem to compile the library,
however, it appears to have found the ext_library/CMakeLists.txt.
The evidence of this is in zephyr_project/lib folder which has some CMake folders that are empty but named the same as
the ext_library/CMakeLists.txt. Other evidence is that the
message(...) commands in both CMakeLists.txt are being printed.
Using both static and relative paths to the ext_library folder.
Using cmake FILE(COPY ...), the files weren't copied. No apparent error.
What has worked:
Manually copying code from the ext_library/source and ext_library/include into the appropriate folders in zephyr_project.
Additional info:
zephyr_project/zephyr/CMakeLists.txt (original + attempt at adding the ext_library as a subdirectory)
cmake_minimum_required(VERSION 3.13.1)
include($ENV{ZEPHYR_BASE}/cmake/app/boilerplate.cmake NO_POLICY_SCOPE)
project(firmware)
set(EXT_LIB "C:/Users/mcelr/Desktop/project/ext_library")
add_subdirectory(${EXT_LIB} ${PROJECT_SOURCE_DIR})
FILE(GLOB app_sources
"../src/*.c*"
)
ext_library/CMakeLists.txt (CMAKE_CURRENT_SOURCE_DIR does point to the correct directory at runtime, as confirmed via removed message(...) logging)
cmake_minimum_required(VERSION 3.13.1)
project(ext_lib)
include_directories(${CMAKE_CURRENT_SOURCE_DIR}/include)
set(LIBRARY_OUTPUT_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/build)
add_library(ext_lib_zephyr STATIC
${CMAKE_CURRENT_SOURCE_DIR}/source/packet.c
${CMAKE_CURRENT_SOURCE_DIR}/source/checksum.c
)
Thank you so much for any advice or hints to solve this,
Austin
I found workaround for it:
cmake_minimum_required(VERSION 3.13.1)
include($ENV{ZEPHYR_BASE}/cmake/app/boilerplate.cmake NO_POLICY_SCOPE)
project(Project_work_queue)
SET(LIB_PATH ../../libs/)
FILE(GLOB lib_sources ${LIB_PATH}*.*)
FILE(COPY ${lib_sources} DESTINATION ../../../src/libs_tmp)
FILE(GLOB app_sources ../src/*.c*)
include_directories(${LIB_PATH})
target_sources(app PRIVATE
${app_sources}
)
And add src/libs_tmp to .gitignore. I know it is ugly way but it works :-P

Making a CMake library accessible by other CMake packages automatically

I have one project that produces a library:
project (myCoolLibrary)
ADD_LIBRARY(my_cool_library SHARED ${mysources_SRC})
And another project that should be using this library:
find_package (myCoolLibrary REQUIRED)
INCLUDE_DIRECTORIES("${myCoolLibrary_INCLUDE_DIRS}" )
add_executable(myCoolExe ${my_sources_SRC} )
TARGET_LINK_LIBRARIES(myCoolExe ${myCoolLibrary_LIBRARIES} )
Is there a way that I can change the first file so that the second file works automatically? That by running CMake on the first file and then running make on the output, then running CMake on the second file, CMake is able to find the package?
An answer where I just give the address of where the first project is built to the second package is also acceptable.
Taking the code found in a blog post by #daniperez - Use CMake-enabled libraries in your CMake project (III) - I've come up with the following minimal solution:
myCoolLibrary/CMakeLists.txt
cmake_minimum_required(VERSION 3.3)
project(myCoolLibrary)
function(my_export_target _target _include_dir)
file(
WRITE "${CMAKE_CURRENT_BINARY_DIR}/${_target}Config.cmake"
"
include(\"\$\{CMAKE_CURRENT_LIST_DIR\}/${_target}Targets.cmake\")
set_property(
TARGET ${_target}
APPEND PROPERTY
INTERFACE_INCLUDE_DIRECTORIES \"${_include_dir}\"
)
"
)
export(TARGETS ${_target} FILE "${CMAKE_CURRENT_BINARY_DIR}/${_target}Targets.cmake")
# NOTE: The following call can pollute your PC's CMake package registry
# See comments/alternatives below
export(PACKAGE ${_target})
endfunction(my_export_target)
...
add_library(${PROJECT_NAME} SHARED ${mysources_SRC})
my_export_target(${PROJECT_NAME} "${CMAKE_CURRENT_SOURCE_DIR}")
myCoolExe/CMakeLists.txt
cmake_minimum_required(VERSION 3.3)
project(myCoolExe)
find_package(myCoolLibrary REQUIRED)
...
add_executable(${PROJECT_NAME} ${my_sources_SRC})
target_link_libraries(${PROJECT_NAME} myCoolLibrary)
To make it reusable I have packed everything into my_export_target(). And I'm friend of self-propagating properties like INTERFACE_INCLUDE_DIRECTORIES.
As commented by #ruslo, using export(PACKAGE ...) can pollute your package registry. So alternatively you can:
Write the target configuration files directly to some dedicated place specific for a certain toolchain
See e.g. How to install your custom CMake-Find module and 0003659: FIND_PACKAGE command improvements.
Set CMAKE_MODULE_PATH via the second project's CMake command line (injecting the search path(s) from the outside). If you are building the two projects anyway with a build script, then this is the most direct way to propagate the module search path(s).
Additional References
export()
CMake/Tutorials/Package Registry
Unable to find Eigen3 with CMake
How to instruct CMake to use the build architecture compiler

CMake execution order - first build shared library then look for it from another project

I have the following cmake setup:
colorizer_root
|
|-------colorizer_lib
|-------colorizer_template_project
The colorizer_root contains the top level CMakeLists.txt which is invoked when running cmake:
colorizer_root CMakeLists.txt
project(colorizer_root)
cmake_minimum_required(VERSION 2.8)
set(CMAKE_BUILD_TYPE Debug)
add_subdirectory(colorizer_lib)
add_subdirectory(colorizer_template_project)
As you can see it contains 2 subdirectories each a project on its own. Basically what the colorizer_lib does is create a shared library named libcolorize.so (no executables here!), which then is to be used by the other project colorizer_template_project (the executable is created in this project). Here are the two CMakeLists.txt files for their respective projects:
colorizer_lib CMakeLists.txt
project(colorizer_lib)
cmake_minimum_required(VERSION 2.8)
set(CMAKE_CXX_FLAGS "--std=gnu++11 ${CMAKE_CXX_FLAGS}")
include_directories(. INCLUDES)
add_library(colorizer SHARED colorizer.cpp)
colorizer_template_project CMakeLists.txt
project(colorizer_template_project)
cmake_minimum_required(VERSION 2.8)
find_library(COLORIZER_LIB colorizer
PATHS ${CMAKE_BINARY_DIR}/colorizer_lib
)
aux_source_directory(. SRC_LIST)
add_executable(${PROJECT_NAME} ${SRC_LIST})
target_link_libraries(${PROJECT_NAME} ${COLORIZER_LIB})
I'm having trouble figuring out how the whole lookup thing works. The problem here is that when I run the top level CMakeLists.txt it goes through both (obviously) but during processing the colorizer_template_project it breaks with a complaint:
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
COLORIZER_LIB
linked by target "colorizer_template_project" in directory /home/USER/Programming/C_Cpp/colorizer/colorizer_template_project
This is an expected behaviour since libcolorizer.so cannot be present at the time of running cmake because it is created after make has been invoked.
How do I tell cmake to first process the first project (including the build step!) and then go to the next one? I know that this works if I add an executable to the project that creates the library and then directly link it to the binary but in this case I want separate projects for the library and the executable that is using it.
PS: I haven't given any details about the sources because they are not important here. It is - I believe - a general question, which is not specific to whether I'm using C, C++ or something similar.
project command doesn't make subprojects independent, so colorizer target is actually accessible for colorizer_template_project, and you can directly link with it:
add_executable(${PROJECT_NAME} ${SRC_LIST})
target_link_libraries(${PROJECT_NAME} colorizer)

CMake and dependencies

I have the following directory structure and library dependencies:
./lib-a
./lib-b (depending on lib-a)
Each directory contains a CMakeLists.txt file for generating its own library.
I am using an out-of-source building policy.
In order to say that lib-b depends on lib-a, I have put the command add_subdirectory(../lib-a lib-a) in ./lib-b/CMakeLists.txt, according to what is taught by the official CMake tutorial. This way I obtain that a subdirectory lib-a is created in ./lib-b/build dir.
This is not the behaviour I desire. What I would like to obtain is CMake making reference to lib-a in generating lib-b and, if lib-a has not been already generated, CMake should generate it inside ./lib-a/build by using the CMakeLists.txt of lib-a (in a behaviour similar to the one of the make tool when dealing with dependencies).
I would also like to add that I am not using a root CMakeLists.txt in my example, but what I would like to have is the lib-b/CMakeLists.txt declaring the dependency on lib-a, thus making lib-a to be compiled, if not already, by using its own lib-a/CMakeLists.txt.
Here is the dirs structure and their contents:
lib-a/
CMakeLists.txt (for compiling lib-a)
src/
test.cpp
include/
test.hpp
lib-b/
main.cpp
CMakeLists.txt (for compiling lib-b; here is the point where I would like to make reference to lib-a, that I need for the generation of lib-b)
lib-b/main.cpp contains also an include of test.hpp of lib-a, because it is using a function of lib-a. This should be taken into consideration in the specification of lib-b/CMakeLists.txt.
What should the content of the two lib-a/CMakeLists.txt and lib-b/CMakeLists.txt files be?
I think you misunderstand the tutorial. The thing that links the libraries together is target_link_library(lib_b lib_a). If the name of the dependency is a library that is part of the build, CMake will magically make the dependencies work. It has nothing to do with subdirectories. In fact, if I have the following directory structure:
./
./a.hpp
./a.cpp
./b.hpp
./b.cpp
./CMakeLists.txt
The following will set the dependencies just fine:
PROJECT(lib_a)
ADD_LIBRARY(lib_a a.hpp a.cpp)
PROJECT(lib_b)
ADD_LIBRARY(lib_b b.hpp b.cpp)
TARGET_LINK_LIBRARIES(lib_b lib_a)
This will work across subdirectory projects as well:
./
./CMakeLists.txt
./lib_a/CMakeLists.txt
./lib_a/a.hpp
./lib_a/a.cpp
./lib_b/CMakeLists.txt
./lib_b/b.hpp
./lib_b/b.cpp
And the list files:
# ./CMakeLists.txt
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
ADD_SUBDIRECTORY(lib_a)
ADD_SUBDIRECTORY(lib_b)
# ./lib_a/CMakeLists.txt
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT(lib_a)
ADD_LIBRARY(lib_a a.hpp a.cpp)
# ./lib_b/CMakeLists.txt
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT(lib_b)
INCLUDE_DIRECTORIES(${lib_a_SOURCE_DIR})
ADD_LIBRARY(lib_b b.hpp b.cpp)
TARGET_LINK_LIBRARIES(lib_b lib_a)