I have a CMake project which consist from a set libraries.
This libraries links with a several programs.
Is it possible to replace compile options, for libraries which build for specifical programs?
For example, when cmake builds library for program A it defines first includes directory, for another program it includes directory B?
Related
I'm currently changing the build system on my project, from gnu makefiles to cmake (that generate makefiles).
My project generates several libraries (.lib), and several executables (.exe).
Currently i generate the makefiles using the following command :
cmake -G "Unix Makefiles" .. -DCMAKE_BUILD_TYPE=Debug
The generated makefiles contain an all target, as well as a target for every executable (compiled as such with the add_executable cmake directive), so i can compile a subset of the project (which saves a lot of time) : make executable_1; make executable_2 and so on.
However, there is no target for the libraries (compiled as such with the add_library cmake directive) so i cannot do make library_1 for example. I want to do this because it would save a lot of time.
I tried to add a dummy executable in the library's cmake, and link the library to this executable (which only contains a main without actually using library_1's code).
add_library(library_1 test.cpp)
add_executable(dummy_exe dummy_main.cpp)
target_link_library(dummy_exe library_1)
It does add a target for dummy_exe but does not build the library because it does not actually need to link any of the library_1's code.
This was a workaround attempt anyway, and i'd rather just call make library_1 after all. Is there any way to add a makefile target for a library using cmake ?
As answered by w-m and Fred, CMAKE indeed create a target for libraries in the Makefile.
I was trying to build the library with the cmake subproject name of the library instead of the library name.
make help was indeed of big help to find this issue, as it lists everything that can be built.
My cmake project builds against external libraries, e.g. Boost. I would now like to advise cmake to generate "make install code" that causes all used external libraries to be added to the installation package.
My hope is that cmake can inspect the built shared objects and executables, e.g. using ldd, to find out which external libraries are required and add them without explicit naming of the individual libraries in the CMakeLists.txt.
Of course there is the other case in which the built code expicitly loads the external libaries (dlopen(), ...), e.g. as done by Intel IPP. In this case I would probably somehow need to explicitly name the libraries to install, e.g. using some variables set by the FindXXX cmake scripts.
I have several projects consisting of a few libraries, each living in its own subdirectory, knitted together by the topmost CMakeLists.txt file. I am in the habit of using project(<DIRNAME>) at the top of each CMakeLists.txt file and I try to structure the subprojects in such a way that they could be compiled separately from the top project. However, while this might make sense for standalone, core libraries, it cannot work for the libraries that depend on them because I need to do stuff like
target_link_libraries(gui core)
And core will nor be defined if I am trying to compile gui as a standalone project.
Is it wrong to use project() in this context, or am I missing something?
A Matter of Taste
This is in my opinion mainly a matter of taste. I don't think multiple project() commands itself are a problem, its more that projects I have seen using this approach tend to repeat itself in other parts and sometimes are running into problems with global cached variables.
Depending Libraries
The more relevant fact is, that the depending libraries will also add an include dependencies.
For standalone static library targets - not executable or shared library targets who really link the library - the simple target_link_libraries() command could be ignored with something like:
if (TARGET core)
target_link_libraries(gui core)
endif()
But the header files include dependency remains.
Standalone Projects in CMake
For me a (sub-)project to be really standalone needs not only the project() command, but it should also have a export(TARGETS ...) command. Then you could e.g. use find_package() commands to resolve any open dependencies with something like:
if (NOT TARGET core)
find_package(core REQUIRED)
endif()
target_link_libraries(gui core)
References
Making cmake library accessible by other cmake packages automatically
CMake share library with multiple executables
I am currently working on migrating from an internal build system to cmake, and I am enjoying it so far.
Our source code is broken up into discrete named components. These components generally will build a library and a set of executables. I have setup cmake with a base CMakeLists.txt and then created a CMakeLists.txt in each code component that is then included in the base. The component CMakeLists.txt have multiple targets in them, one for a library and then a variable number of executables.
With our current system you can type something like:
make component_name
and that will build a library and any executables associated with component_name. Is something like that possible with cmake? Can I use one name to build all of the targets in a CMakeLists.txt file?
First define a custom target, then define the dependencies of the target:
ADD_CUSTOM_TARGET(component_name)
ADD_DEPENDENCIES(component_name lib1 lib2 exe1 exe2)
I'm considering to use CMake for projects targeting a microcontroller. I found out how to create a toolchain file and invoke cmake -DCMAKE_TOOLCHAIN_FILE=Path/To/Toolchain.cmake to make CMake do cross-compiling.
However most projects that I work on have also code that must be compiled for the host platform. These are often unit tests or other test tools, which share most part of their code with the binary that will run on the microcontroller. A rare case might be a project that even has two processors having a different instruction architectures, thus needing a host compiler and two different cross compilers.
I'd like to have one build that rules them all. Is it possible to have a construction that I only need to call cmake /path/to/source && make, or is the only solution having multiple 'root' CMakeList.txt files, each for every target?
Each cmake run will target one specific generator and thus one platform.
What you want can be achieved by having one hierarchy of CMakeLists files for each platform. You need to get to a point where doing a succession of cmake .. && make calls will build the whole project.
Then write a master CMakeLists that executes all of those separate build steps for you, e.g. through ExternalProject_Add or by using custom commands. Depending on the structure of your project it might make sense to have only the tools required for building being processed this way and add the sources for the actual project directly to the master CMakeLists instead.