When I try to build an specific application using cmake 2.8.9, everything seems fine at first. cmake tells me that all the required header files and libraries are found, no errors. However, when I run make the build fails because of missing header files. These header files where found by cmake just seconds before running make.
I want to find out why cmake can find the file, but make cannot. How can I debug this?
Sounds like CMake "found" the headers by running a Find module, which finds files on disk and stores these in CMake variables. These variables must then be used to configure the targets defined in the CMakeList, and perhaps this step is missing in your CMakeList. Check all find_package() calls in the CMakeList and make sure their results are used where necessary.
Here's an example how that could look for a simple library (GLUT):
find_package(GLUT) # find GLUT
include_directories(${GLUT_INCLUDE_DIR}) # use variable set up by find_package() call
add_target(MyGlutUsingProgram main.cpp)
target_link_libraries(${GLUT_LIBRARIES}) # use variable set up by find_package() call
Related
I'm trying to use add_custom_command to generate a file during the build. The command never seemed to be run, so I made this test file.
cmake_minimum_required( VERSION 2.6 )
add_custom_command(
OUTPUT hello.txt
COMMAND touch hello.txt
DEPENDS hello.txt
)
I tried running:
cmake .
make
And hello.txt was not generated. What have I done wrong?
The add_custom_target(run ALL ... solution will work for simple cases when you only have one target you're building, but breaks down when you have multiple top level targets, e.g. app and tests.
I ran into this same problem when I was trying to package up some test data files into an object file so my unit tests wouldn't depend on anything external. I solved it using add_custom_command and some additional dependency magic with set_property.
add_custom_command(
OUTPUT testData.cpp
COMMAND reswrap
ARGS testData.src > testData.cpp
DEPENDS testData.src
)
set_property(SOURCE unit-tests.cpp APPEND PROPERTY OBJECT_DEPENDS testData.cpp)
add_executable(app main.cpp)
add_executable(tests unit-tests.cpp)
So now testData.cpp will generated before unit-tests.cpp is compiled, and any time testData.src changes. If the command you're calling is really slow you get the added bonus that when you build just the app target you won't have to wait around for that command (which only the tests executable needs) to finish.
It's not shown above, but careful application of ${PROJECT_BINARY_DIR}, ${PROJECT_SOURCE_DIR} and include_directories() will keep your source tree clean of generated files.
Add the following:
add_custom_target(run ALL
DEPENDS hello.txt)
If you're familiar with makefiles, this means:
all: run
run: hello.txt
The problem with two existing answers is that they either make the dependency global (add_custom_target(name ALL ...)), or they assign it to a specific, single file (set_property(...)) which gets obnoxious if you have many files that need it as a dependency. Instead what we want is a target that we can make a dependency of another target.
The way to do this is to use add_custom_command to define the rule, and then add_custom_target to define a new target based on that rule. Then you can add that target as a dependency of another target via add_dependencies.
# this defines the build rule for some_file
add_custom_command(
OUTPUT some_file
COMMAND ...
)
# create a target that includes some_file, this gives us a name that we can use later
add_custom_target(
some_target
DEPENDS some_file
)
# then let's suppose we're creating a library
add_library(some_library some_other_file.c)
# we can add the target as a dependency, and it will affect only this library
add_dependencies(some_library some_target)
The advantages of this approach:
some_target is not a dependency for ALL, which means you only build it when it's required by a specific target. (Whereas add_custom_target(name ALL ...) would build it unconditionally for all targets.)
Because some_target is a dependency for the library as a whole, it will get built before all of the files in that library. That means that if there are many files in the library, we don't have to do set_property on every single one of them.
If we add DEPENDS to add_custom_command then it will only get rebuilt when its inputs change. (Compare this to the approach that uses add_custom_target(name ALL ...) where the command gets run on every build regardless of whether it needs to or not.)
For more information on why things work this way, see this blog post: https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/
This question is pretty old, but even if I follow the suggested recommendations, it does not work for me (at least not every time).
I am using Android Studio and I need to call cMake to build C++ library. It works fine until I add the code to run my custom script (in fact, at the moment I try to run 'touch', as in the example above).
First of,
add_custom_command
does not work at all.
I tried
execute_process (
COMMAND touch hello.txt
)
it works, but not every time!
I tried to clean the project, remove the created file(s) manually, same thing.
Tried cMake versions:
3.10.2
3.18.1
3.22.1
when they work, they produce different results, depending on cMake version, one file or several. This is not that important as long as they work, but that's the issue.
Can somebody shed light on this mystery?
I need to build libpng, but without #define PNG_READ_eXIf_SUPPORTED in pnglibconf.h
I've read comments from pnglibconf.dfa, and here are some ways of disabling features, however I didn't manage to make what I want using them.
The problem is in that, build process is performed on build server, so I can't change any files inside of libpng submodule. Here is how server works:
Download clone sources from git
Generate makefile by running cmake ..
Run make command.
Thus I have libnpg, but with included PNG_READ_eXIf_SUPPORTED option.
Libpng is a submodule of my project, so it checked out by build server automatically so I can't change pnglibconf manually.
As it said in pnglibconf.dfa file:
There are three ways of disabling features, in no particular order:
1) Create 'pngusr.h', enter the required private build information
detailed below and #define PNG_NO_<option> for each option you
don't want in that file in that file. You can also turn on options
using PNG_<option>_SUPPORTED. When you have finished rerun
configure and rebuild pnglibconf.h file with -DPNG_USER_CONFIG:
make clean
CPPFLAGS='-DPNG_USER_CONFIG' ./configure
make pnglibconf.h
pngusr.h is only used during the creation of pnglibconf.h, but it
is safer to ensure that -DPNG_USER_CONFIG is specified throughout
the build by changing the CPPFLAGS passed to the initial ./configure
I tried to do what is written here. I run cmake .. -DCMAKE_C_FLAGS="-DPNG_USER_CONFIG -I/home/me/dev/include" where /home/me/dev/include - is a path to pngusr.h file
Then I run make command. However, PNG_READ_eXIf_SUPPORTED is still present in generated (by make command pnglibconf.h file).
So my main question is how to make libpng without PNG_READ_eXIf_SUPPORTED option?
It remains unclear to me whether and to what extent the specific customization mechanism you are trying to use works in the version of libpng you are trying to use. But it looks like there's a simpler way. Just below the excerpt you posted, in the same file, is the second (of three) alternatives:
2) Add definitions of the settings you want to change to CPPFLAGS;
for example:
-DPNG_DEFAULT_READ_MACROS=0
(lightly formatted). I'm not in a good position to test that on the CMake-based build system, but it seems to work like a charm in the Autotools build system. From examining and comparing the two, I think it will work for CMake, too. In particular, you would want to run
cmake .. -DCMAKE_CPP_FLAGS="-DPNG_NO_READ_eXIf"
for your particular case.
Note, by the way, that the CPP (i.e. preprocessor) flags are the right place for an option such as you are specifying (for -DPNG_USR_CONFIG in your original attempt, too). In practice, though, they probably still work in the C compiler flags.
I have a complex build I'm trying to sort out on a new build server. Using CMake for creating the makefiles. Old version of CMake on a different server was 2.8.5. New version is 2.8.12.2. For some reason, the autogenerated CMakeDirectoryInformation.cmake files are missing the CMAKE_C_INCLUDE_PATH and CMAKE_CXX_INCLUDE_PATH, which specify the absolute location of the include headers available to that particular directory. Without that information, the source code in that directory that references headers via a local path (such as foo.h versus ../../../asdf/foo.h) won't compile. Any ideas why these are missing? As far as I can tell this is supposed to be autogenerated by CMake.
I found a useful command that got me further into my build:
SET(CMAKE_INCLUDE_DIRECTORIES_BEFORE ON)
But that didn't actually solve my problem. The real issue was that in one of my CMakeLists.txt files I had:
include_directories(
$[XXXX_INCLUDE_DIR}
)
The '[' bracket was causing the build to fail because that include directory was not being used. However, on the old build server, it had no issue with this square bracket.
I'm creating a application that is using a pre-compiled third party shared library files.To use these I'm required to set the LD_LIBRARY_PATH or create a conf file under /etc/ld.so.conf.d/application.conf, My problem is There is a system libcurl.so.4 already available under /usr/lib/.The third party Library also has a libcurl.so.4 . If I create /etc/ld.so.conf.d/application.conf file, I'm not able to use "YUM installer" .
I'm getting the error
Pycurl error occured ,
Compile time Version is higher than the Linking version
I'm worried to remove the application libcurl.so.4 as it may break the features in that third party library that I'm making use of(making my application meaning less) and I can't neglect the system library either .
Is it possible to use these two libraries without any conflict as I mentioned above.
PS : Setting LD_LIBRARY_PATH too causes the same problem
Create a script that sets and exports $LD_LIBRARY_PATH before invoking the executable. The variable will disappear once the script exits.
If you have 2 conflicting libs and one is system, another one is a user app, don't put application.conf into /etc/ld.so.conf.d/. Instead use something like ~your_user_name/custom_conf , put your application.conf file there (eventually you may need to edit it adding the path to the proper version of libcurl.so.4). libcurl.so.4 should be not in system dirs as well rather in ~your_user_name/lib. You can make a wrapper for your app where you set $LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~your_user_name/lib as Ignacio Vazquez-Abrams suggested or compile your app explicitly pointing out which library to link (use linker flags -L /full/path/to/your/libcurl.so.4)
I can't seem to find much about this, so maybe it isn't possible... or I am searching with the wrong keywords.
Anyway, I have a directory of source. Let's say that there is a folder within Source called Tests and another called Products. I have the usual hierarchy of CMakeLists.txt files so that I can build all the source in each directory and subdirectory, etc... What I want to know is if it is possible to pass a command line argument with cmake so that it will only build the tests folder or the source folder.
e.g. something like cmake TEST ..
Thanks
Of course you can use flags.
if(TEST)
include needed folders
else()
do something else
endif()
And call cmake like this:
cmake -DTEST=1 ..
You can create them as different targets. CMake will configure all of them, but then you can run make test or make product. An example would be:
project(myProject)
add_subdirectory(tests)
add_subdirectory(products)
add_executable(test EXCLUDE_FROM_ALL ${TEST_SRC_FILES})
add_executable(product EXCLUDE_FROM_ALL ${PRODUCT_SRC_FILES})
In each subdirectory you would have a CMakeLists.txt that builds the source file variables. The EXCLUDE_FROM_ALL means that just typing make won't build either tests or products, but you can decide if you want that to happen or not.
To build, you can do make test or make product and it will build only that target (and any dependencies).