I am currently working on transitioning over a Visual C++ project (that has multiple subprojects inside of it) over to CMake.
There is one thing that I am not sure about – basically, to include the subprojects from the top level CMakeLists.txt file, I just utilize the add_subdirectory command, and reference the directories that these various subprojects are stored under.
However, I have one project that is in the same directory as my top level CMakeLists.txt file, and so I am wondering if it is still possible to include this file somehow? CMake does not allow me to call add_subdirectory on the existing PROJECT_BINARY_DIR (see below):
add_subdirectory(${PROJECT_BINARY_DIR}) #not allowed in CMake
I cannot think of another way for me to include this subproject into my CMake build. Any ideas?
All add_subdirectory does is add a subdirectory with a CMakeLists.txt file in it, and so it would not make sense to allow you to add the current directory. You can simply add the CMake logic to build that part of your project in the CMakeLists.txt file. If you would like to separate the logic, then you could put it in build_project.cmake, and then use include,
include(build_project.cmake)
You can include as many other CMake files as you like, and that CMake code will be evaluated as if it was pasted inline. So all the normal add_executable and similar commands would work.
Related
I'm trying to put together a CMake project where I have different packages that I need to build. This is my desired structure:
package1
src
file.cpp
test
file_test.cpp
package2
src
file2.cpp
test
file2_test.cpp
CMakeLists.txt
main.cpp // this will be removed later
This is my current CMakeLists.txt file:
cmake_minimum_required(VERSION 3.10)
# set the project name
project(cppApp)
# specify the C++ standard
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED True)
include_directories(${PROJECT_SOURCE_DIR})
# add the executable
add_executable(cppApp main.cpp ./package1/src/file.cpp ./package2/src/file2.cpp)
So the question is firstly, is a library considered a package in CMake? This question comes from someone who have done a lot of Java where I would typically call that a package and not a library. But does it in CMake?
Also, how do I in CMake include all files in the "packages" to be built instead of hard coding in the files as an executable? If I create many .cpp/.h files I want to automate this as much as possible.
I have seen that some other projects use a CMakeLists.txt file inside each "package", is this ideal? And is this good practice?
If you have a better suggestion according to some standard I should use to structure my project I would like to know a good one as well.
So the question is firstly, is a library considered a package in
CMake? This question comes from someone who have done a lot of Java
where I would typically call that a package and not a library. But
does it in CMake?
Your definition of package in Java is not quite accurate. Package is just a mean to organize classes in Java in namespace manner. It could be classes of a separate library, but nothing prevents you from using different packages within the same project. It has nothing to do with CMake packages, where each package is actually a whole separate project.
I have seen that some other projects use a CMakeLists.txt file inside
each "package", is this ideal? And is this good practice?
CMakeLists.txt files in subdirectories merely define new subset of rules for those directories. In order to make your CMake project respect those rules, you add such directory with add_subdirectory. It's not neccessarily a separate library, you can make subset of rules for parts of a single project, and it's usually a good idea to do that if some files are really that different.
CMake have something called add_library(lib) and is those kinds of directories considered a library?
add_library creates so-called CMake target, just like add_executable. The targets can be linked with each other with use of target_link_libraries, and that will indeed be considered a library in terms of C++.
Is it possible to specify build directory within CMakeLists file? If yes, how.
My aim is to be able to call "cmake" within top level source directory and have cmake figure out the build directory.
Afaik, with CMake the build directory is always the directory from where you invoke the cmake or ccmake command. So if you want to change the build directory, you have to change directories before running CMake.
To control the location where executables, static and shared libraries are placed once finished, you can modifiy CMAKE_RUNTIME_OUTPUT_DIRECTORY, CMAKE_ARCHIVE_OUTPUT_DIRECTORY, and CMAKE_LIBRARY_OUTPUT_DIRECTORY respectively.
By design, there is not a way to specify that in CMakeLists.txt. It is designed for the user to be able to build the project in whatever directory they want. The typical workflow is:
Check out the project source code.
Go to desired build directory, or the source dir if you plan to do an in-source build.
Run cmake or ccmake to configure the project in that build directory.
Build your project.
All of the directories specified within your CMakeLists.txt should be relative to the ${PROJECT_BINARY_DIR} and ${PROJECT_SOURCE_DIR} variables. In this way, your code becomes buildable across different platforms, which is the goal of CMake.
Using CLion, I have a project structure that looks like this:
You'll see that in the root there are an include directory, a src directory, a lib directory, a cmake-build-debug directory, a CMakeLists.txt file (see red arrow), and a tests directory. The project builds a shared object into lib using the root-level CMakeLists.txt file and the various source, header, and external files.
I can successfully run the root-level CMakeList.txt file and build the library. So far, so good.
Here is the issue. In addition to the above, I am now interested -- on an informal, exploratory basis -- in testing some of the code in the project. To that end, as an initial example, I have created a test_nnls directory with its own CMakeLists.txt (see yellow arrow) file and a test_nnls.cpp file. The code in test_nnls.cpp creates some dummy data, calls a function in src/nnls.cpp, and prints the results. The build process here just creates an executable that does this. This approach is not meant to be part of any formal test framework and I do not want the test to run as part of the root-level build. This is just me adding a simple test program in the overall project that I would like to compile and run on an independent basis when I feel the need. I plan to possibly implement a formal test framework later, but at present I don't know how to do this and for now just need to print some simple output to see if the chosen code is working correctly.
The problem is that I cannot seem to execute the CMakeLists.txt file (yellow arrow) to build the test. It does not appear to be possible in CLion to set up a build for the test program using cmake. How do I structure all of this to get what I want? Thanks.
You don't execute a CMakeLists.txt. It is read by cmake (the root CMaksLists.txt file), which is called by CLion. However, CLion only passes the root CMaksLists.txt file to cmake. Even if you call cmake yourself you would only pass this root CMaksLists.txt file.
If you want to define targets (or anything) in other CMaksLists.txt files located in other folders, then you must add add_subdirectory(folder_name_that_contains_another_CMakeLists_file) to your root CMaksLists.txt file. Only then targets in these other CMaksLists.txt files will appear in CLion.
Note that a few things should appear in the root CMaksLists.txt file, but not in the other ones. Particularly, the two lines below should only be in the root file
cmake_minimum_required(VERSION 3.14) # Choose the minimum cmake version
project(name_of_your_project)
I have downloaded an SDK written in C++ (OPC UA) that creates a .exe file on compiling with Visual Studio 2015. It has a bunch of CMake files. How could one see if it is possible to generate a .dll from such an SDK? Do the CMake files have this information or should there be any macros inside the headers I would have to search for ? The SDK has Visual Studio sample projects (.sln) that I am using to create .exe.
The CMakeLists.txt looks like this
project(uasdk)
cmake_minimum_required(VERSION 2.8.0 FATAL_ERROR)
set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/cmake ${CMAKE_MODULE_PATH})
set_property(GLOBAL PROPERTY USE_FOLDERS ON)
include(CMakeDependentOption)
include(MessageUtils)
display_project_header("true")
if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/src")
add_subdirectory(src)
endif ()
if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/examples")
add_subdirectory(examples)
endif ()
# set CMAKE_INSTALL_MESSAGE to LAZY by default to hide 'Up to date' output when building INSTALL target
if (NOT ${CMAKE_VERSION} VERSION_LESS "3.1")
set(CMAKE_INSTALL_MESSAGE LAZY CACHE STRING "")
set(CMAKE_INSTALL_MESSAGE_VALUES "ALWAYS;LAZY;NEVER")
set_property(CACHE CMAKE_INSTALL_MESSAGE PROPERTY STRINGS ${CMAKE_INSTALL_MESSAGE_VALUES})
endif ()
The questions that already have been asked regarding this topic are from the people who are writing their own code. I intend to use the code from the SDK. Apart from changing the CMAKE file to include the dll do I need to make changes in the source code as well?
It has a bunch of CMake files. How could one see if it is possible to generate a .dll from such an SDK? Do, the CMake files have this information or should there be any MACROS inside the headers I would have to search for ?
If the CMake project generates a library, then the statement add_library must appear somewhere. Note, however, that hierarchies of CMakeLists.txt files are possible, for example, the CMakeLists.txt you included adds two subdirectories. Consider the CMakeLists.txt files in there as well. Since an executable is generated, a call to add_executable must appear somewhere as well.
I intend to use the code from the SDK. Apart from changing the CMAKE file to include the dll do I need to make changes in the source code as well?
I am not familiar with this SDK, but I would guess that examples contains the sources for the executable and src contains the sources for a library. If you just want to try something out, you can modify the example code or add a new example. In this case, you only have to modify the CMakeLists.txt in the examples directory (i.e., add your new source code file).
If you want to use the SDK as external dependency, check whether there is a FindNameofmySDK.cmake included in the CMake modules list or whether there is a NameofmySDK-config.cmake somewhere in the SDK sources or your installation. In this case, you can create a CMake project for your application and use find_package to look for the SDK.
TL;DR I basically want a modular solution of this question. Not only one solution with everything in it, but also a solution for each executable alone.
In my question here I wanted to know how I should split my CMakeLists.txt among different folders. Some folders contain code that will be a static library and some code will be executables or dynamic libraries that build on those static libraries.
Folder structure looks like this:
/path/to/base/
CMakeLists.txt
app1/
<src files for app1>
CMakeLists.txt
app2/
<src files for app2>
CMakeLists.txt
lib/
<src files for lib>
CMakeLists.txt
If I take the approach of having a CMakeLists.txt in the parent folder to all my libraries and executables and from the include all the directories I have the problem that when I generate VS projects/solutions that my projects for each target contains all the projects - not only the ones necessary for my intended target.
Contents of CMakeLists.txt in the base folder:
cmake_minimum_required(VERSION 3.1)
add_subdirectory(lib)
add_subdirectory(app1)
add_subdirectory(app2)
and the CMakeLists.txt in the app1 folder (app2 is equivalent)
cmake_minimum_required(VERSION 3.1)
project(app1)
add_executable(app1 <src of app1>)
target_link_libraries(app1 lib)
and CMakeLists.txt of lib:
add_library(lib <src of lib>)
If I run cmake on the CMakeLists.txt from base the solution contains all the projects. And even if I open just one of the projects; it also contains everything. VS project of app1 also builds app2 - which I don't want.
If I only run cmake on the CMakeLists.txt of app1 I get a solution which doesn't contain app2 but it also doesn't contain lib, because that's only mentioned for linking inside the cmake file and not as a target (it's in the base file)
CMake will create a solution for each call to project, which will then include all the targets of the current directory and its subdirectories (regardless whether they were defined before or after the actual call to project).
Here's what a well-behaved CMake script should do: Each CMakeLists that you want to be able to act as a root of its own sub-tree within the larger project should start with a cmake_minimum_required call, followed by the project call. Writing project in a CMakeLists basically means: This is a fully self-contained component that can be built independently, even if you delete all the files from its parent directories. As such, it makes sense to have a separate solution for each such project.
With this in mind we can see why this doesn't work in your case: Your apps are not fully self-contained, they depend on lib. The solution to this is to write the build scripts for the apps as if lib was provided as a third-party component, with find_package calls and everything.
In the compound build, you already have a target for lib, so the script invoked by the find_package call should be made to short-circuit to using that target and only actually go scavenging the system if it cannot find that existing target.
Also read up on how CMake's packaging system works, which provides some automation to handle such cases pretty elegantly.