I am trying to copy a directory using a CMake script.
execute_process(COMMAND ${CMAKE_COMMAND} -E tar czf "${name}.orig.tar.gz" "${folder}"
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/Debian)
but it is throwing an error.
CMake Error: archive_write_header: Can't translate pathname 'files/osgModels/textures/índice.jpeg' to UTF-8
Now I end up with an archive which doesn't contain all the files.
However I can successfully create the archive when running tar independently, i.e. not using CMake.
I think you're seeing this CMake bug which was resolved after version 2.8.12.2. I'm not sure whether the fix made it into 3.0.0 or if it was 3.0.1, but either way, if you update CMake to the current version, you should see the problem disappear.
(I expect the í character of índice is the problem here)
Related
So I have CLion IDE and I wonder if I can use Cmake that my CLion use straightly from terminal. Because the system tells me that cmake isn't installed so there is no cmake in /usr/bin.
Sure, all you need to do is find the absolute path to the CMake binary bundled with your CLion installation.
# This can help you find the binary if you don't know where it is
# Substitute <dir> for where you want to search on the system
$ find <dir> -executable -type f -name cmake
# It will give you can output like this
/usr/foobar/baz/clion/cmake/3.24.0/bin/cmake
Then you'll just need to add CMake to your path.
Here is some bash code that does that:
PATH="/usr/foobar/baz/clion/cmake/3.24.0/bin:$PATH"
export PATH
Place the above code in your .bash_aliases or your .bashrc whichever approach you prefer. So that the PATH is persistently modified in your terminal sessions.
Then reload .bashrc
$> source .bashrc
Then you'll know you succeeded when you get a result like this:
$ cmake --version
cmake version 3.24.0
CMake suite maintained and supported by Kitware (kitware.com/cmake).
I have been using autotools for a few years, and I'm learning CMake now for new projects.
Here is what I have:
myfirstrecipe.bb:
inherit pkgconfig cmake
...
do_install() {
install -d ${D}${datadir}/folder1/folder2
install -m 0755 ${S}/files/file.txt ${D}${datadir}/folder1/folder2
}
mysecondrecipe.bb:
...
DEPENDS = "myfirstrecipe"
...
This works fine. The second recipe can find the file.txt installed by the first recipe, which I see it is installed in the secondrecipe sysroot:
build/tmp/work/armv7ahf-vfp-os-linux-musleabi/mysecondrecipe/510-r0/mysecondrecipe-sysroot/usr/share/folder1/folder2/file.txt
However I want CMake to install the file instead. So when I try this:
myfirstrecipe.bb:
inherit pkgconfig cmake
...
OECMAKE_TARGET_INSTALL = "file-install"
CMakeLists.txt:
add_custom_target(file-install)
add_custom_command(TARGET file-install POST_BUILD
COMMAND ${CMAKE_COMMAND} -E make_directory ${CMAKE_INSTALL_DATADIR}/folder1/folder2
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${CMAKE_SOURCE_DIR}/files/file.txt
${CMAKE_INSTALL_DATADIR}/folder1/folder2/)
Then I get a build error from mysecondrecipe.bb saying it could not find the file since it is not installed. I see it installed here:
build/tmp/work/armv7ahf-vfp-os-linux-musleabi/myfirstrecipe/1.0-r0/myfirstrecipe-1.0/share/folder1/folder2/file.txt
But not in the path above. Anyone can see what I am missing? If I were to use Autotools I could easily get this working with this:
Automake.am:
file-install: $(shell find files/ -type f -name '*.txt')
mkdir -p ${DESTDIR}${datadir}/folder1/folder2
cp -u $^ -t ${DESTDIR}${datadir}/folder1/folder2
Basically you do not use the standard way of installing files.
CMake has an install directive install, wich is commonly used and powerfull.
Doing so, leads to the nice situation, that Within myfirstrecipe.bb an own do_install task is not necessary. The cmake.bbclass, you already inherit, is adding a do_install task and relies on the install directive within your CMakeLists.txt
You can take a look at the cmake.bbclass to see how it is implemented. It's at poky/meta/classes/cmake.bbclass
I guess that switching to install will make life easier
This seems to be a common problem without a clear answer.
The situation is: we have a 3rd party dependency that we want to install at build time when building a target that depends on it. That's roughly:
ExternalProject_Add(target-ep
DOWNLOAD_COMMAND <whatever>
BUILD_COMMAND ""
INSTALL_COMMAND ""
CONFIGURE_COMMAND "")
add_library(target-imp STATIC IMPORTED)
set_target_properties(target-imp PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES /path/to/install/include
IMPORTED_LOCATION /path/to/install/lib/libwhatever.a)
add_library(target INTERFACE)
target_link_libraries(target INTERFACE target-imp)
add_dependencies(target target-ep)
(It takes three to tango here because of cmake issue 15052)
When using Unix Makefiles as the generator, this works great. Only installs dependencies on demand, all the builds work correctly.
However, on Ninja, this fails immediately with something like:
ninja: error: '/path/to/install/lib/libwhatever.a', needed by 'something', missing and no known rule to make it
This is because Ninja scans dependencies differently from Make (see ninja issue 760). So what we have to do is actually tell Ninja that this external dependency exists. We can do that:
ExternalProject_Add(target-ep
DOWNLOAD_COMMAND <whatever>
BUILD_BYPRODUCTS /path/to/install/lib/libwhatever.a
BUILD_COMMAND ""
INSTALL_COMMAND ""
CONFIGURE_COMMAND "")
Which unfortunately also fails with:
No build step for 'target-ep'ninja: error: mkdir(/path/to/install): Permission denied
This is because my download step has permissions to write to that path, but whatever mkdir command is being run by the underlying add_custom_command() from with ExternalProject_Add() does not.
So:
Is this possible at all with Ninja and CMake? (Version is not an issue, I can use the latest CMake if that solves the problem)
If there is some way to workaround with explicitly listing BUILD_BYPRODUCTS, is there a way to simply communicate that the entire directory that will get installed is a byproduct? That is, /path/to/install/* is a byproduct?
The hidden mkdir step of ExternalProject (which all other steps directly or indirectly depend on) always tries to create the full set of directories, even if they won't be used. You can see this here. For reference, it does this:
ExternalProject_Add_Step(${name} mkdir
COMMENT "Creating directories for '${name}'"
COMMAND ${CMAKE_COMMAND} -E make_directory ${source_dir}
COMMAND ${CMAKE_COMMAND} -E make_directory ${binary_dir}
COMMAND ${CMAKE_COMMAND} -E make_directory ${install_dir}
COMMAND ${CMAKE_COMMAND} -E make_directory ${tmp_dir}
COMMAND ${CMAKE_COMMAND} -E make_directory ${stamp_dir}${cfgdir}
COMMAND ${CMAKE_COMMAND} -E make_directory ${download_dir}
COMMAND ${CMAKE_COMMAND} -E make_directory ${log_dir} # This one only since CMake 3.13
)
The default install location on Unix systems is probably going to be /usr/local, so if you don't have write permissions to all of the directories it tries to make, then that may be related to your problem. I suggest you check the permissions of each of these locations and make sure they either already exist or are writable. Alternatively, you could specify an install directory that is local to the build tree so that even though it won't be used, it can at least always be created (see example further below).
If you use Ninja, it will be more rigorous in its dependency checking than make. You have target-ep doing the download that provides libwhatever.a, so you do need BUILD_BYPRODUCTS to tell Ninja that target-ep is what creates that file. As you've found out, if you don't then target-imp will point at a library that won't initially exist and Ninja rightly complains that it is missing and it doesn't know how to create it. If you provide BUILD_BYPRODUCTS, it makes sense that the build step shouldn't be empty, so you probably need to do something as a build step, even if it is just a BUILD_COMMAND that doesn't actually do anything meaningful.
The following modified definition of target-ep should hopefully get things working for you:
ExternalProject_Add(target-ep
INSTALL_DIR ${CMAKE_CURRENT_BUILD_DIR}/dummyInstall
DOWNLOAD_COMMAND <whatever>
BUILD_BYPRODUCTS /path/to/install/lib/libwhatever.a
BUILD_COMMAND ${CMAKE_COMMAND} -E echo_append
INSTALL_COMMAND ""
CONFIGURE_COMMAND "")
Your original question also creates a dependency on the wrong target. target-imp should depend on target-ep, but you had target depend on target-ep instead. The correct dependency can be expressed by this:
add_dependencies(target-imp target-ep)
With the BUILD_BYPRODUCTS option, Ninja already knows the above dependency, but it is needed for other generators, including make.
You haven't specified what your <whatever> download command does, but I'm assuming it is responsible for ensuring that the library will exist at /path/to/install/lib/libwhatever.a when it has executed. You could also try making the DOWNLOAD_COMMAND empty and putting <whatever> as the BUILD_COMMAND instead.
To address your specific questions:
Is this possible at all with Ninja and CMake? (Version is not an issue, I can use the latest CMake if that solves the problem)
Yes, I verified that the approach mentioned above works with Ninja 1.8.2 for a dummy test project on macOS using CMake 3.11.0. I would expect it to work with CMake 3.2 or later (that's when support for the BUILD_BYPRODUCTS option was added).
If there is some way to workaround with explicitly listing BUILD_BYPRODUCTS, is there a way to simply communicate that the entire directory that will get installed is a byproduct? That is, /path/to/install/* is a byproduct?
Unlikely. How would Ninja know what is expected to be in such a directory? The only way to get reliable dependencies would be to explicitly list each file that was expected to be there, which you do using BUILD_BYPRODUCTS in your case.
If you're willing to download at configuration time, you could follow this post. It uses google-test as the example, but I've used the same technique for other dependencies. Just put your ExternalProject code in a separate file, say "CMakeLists.txt.dependencies" and then launch another cmake with execute_process. I use configure_file first to inject configuration information into the external project and to copy it into the build tree.
configure_file(CMakeLists.txt.dependency.in dependency/CMakeLists.txt)
execute_process(COMMAND "${CMAKE_COMMAND}" -G "${CMAKE_GENERATOR}" .
WORKING_DIRECTORY "${CMAKE_BINARY_DIR}/dependency" )
execute_process(COMMAND "${CMAKE_COMMAND}" --build .
WORKING_DIRECTORY "${CMAKE_BINARY_DIR}/dependency" )
I do this at configuration time so find_package and find_library commands can work on the dependencies.
And now it doesn't matter what generator you use.
I have a problem with the global environmental variable CMAKE_PREFIX_PATH. I already set this and I can see it is set when I type env, but when I run cmake . to build HipHop, it tells me that the variable isn't set.
Is there a way I can hard-code this into the makefiles?
Try to run cmake -DCMAKE_PREFIX_PATH=/your/path .
CMAKE_PREFIX_PATH works as a build directive, rather than as an environment variable. Moreover, you may perform the build into a dedicated temporary directory (it's cleaner, because when done, you can remove that temporary directory and you get back a clean pristine source tree).
$ mkdir -p tmpbuild && cd tmpbuild
$ cmake -DCMAKE_PREFIX_PATH=~/deliveries/hiphop ..
$ make install
$ cd ..
On MacOS it's different. I had to use:
make -i CMAKE_PREFIX_PATH="/the/path"
This was while installing VMQT, and this error was shown:
CMake Error at CMakeLists.txt:87 (find_package): By not providing
"FindOpenCV.cmake" in CMAKE_MODULE_PATH this project has asked CMake
to find a package configuration file provided by "OpenCV", but CMake
did not find one.
Could not find a package configuration file provided by "OpenCV"
with any of the following names:
OpenCVConfig.cmake
opencv-config.cmake
Add the installation prefix of "OpenCV" to CMAKE_PREFIX_PATH or set
"OpenCV_DIR" to a directory containing one of the above files. If
"OpenCV" provides a separate development package or SDK, be sure it
has been installed.
Used this to solve it: make -i CMAKE_PREFIX_PATH="/opt/homebrew/Cellar/opencv/4.6.0_1/lib/cmake/opencv4/"
I do cmake . && make all install. This works, but installs to /usr/local.
I need to install to a different prefix (for example, to /usr).
What is the cmake and make command line to install to /usr instead of /usr/local?
You can pass in any CMake variable on the command line, or edit cached variables using ccmake/cmake-gui. On the command line,
cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr . && make all install
Would configure the project, build all targets and install to the /usr prefix. The type (PATH) is not strictly necessary, but would cause the Qt based cmake-gui to present the directory chooser dialog.
Some minor additions as comments make it clear that providing a simple equivalence is not enough for some. Best practice would be to use an external build directory, i.e. not the source directly. Also to use more generic CMake syntax abstracting the generator.
mkdir build && cd build && cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr .. && cmake --build . --target install --config Release
You can see it gets quite a bit longer, and isn't directly equivalent anymore, but is closer to best practices in a fairly concise form... The --config is only used by multi-configuration generators (i.e. MSVC), ignored by others.
The ":PATH" part in the accepted answer can be omitted. This syntax may be more memorable:
cmake -DCMAKE_INSTALL_PREFIX=/usr . && make all install
...as used in the answers here.
Note that in both CMake and Autotools you don't always have to set the installation path at configure time. You can use DESTDIR at install time (see also here) instead as in:
make DESTDIR=<installhere> install
See also this question which explains the subtle difference between DESTDIR and PREFIX.
This is intended for staged installs and to allow for storing programs in a different location from where they are run e.g. /etc/alternatives via symbolic links.
However, if your package is relocatable and doesn't need any hard-coded (prefix) paths set via the configure stage you may be able to skip it.
So instead of:
cmake -DCMAKE_INSTALL_PREFIX=/usr . && make all install
you would run:
cmake . && make DESTDIR=/usr all install
Note that, as user7498341 points out, this is not appropriate for cases where you really should be using PREFIX.
The way I build CMake projects cross platform is the following:
/project-root> mkdir build
/project-root> cd build
/project-root/build> cmake -G "<generator>" -DCMAKE_INSTALL_PREFIX=stage ..
/project-root/build> cmake --build . --target=install --config=Release
The first two lines create the out-of-source build directory
The third line generates the build system specifying where to put the installation result (which I always place in ./project-root/build/stage - the path is always considered relative to the current directory if it is not absolute)
The fourth line builds the project configured in . with the buildsystem configured in the line before. It will execute the install target which also builds all necessary dependent targets if they need to be built and then copies the files into the CMAKE_INSTALL_PREFIX (which in this case is ./project-root/build/stage. For multi-configuration builds, like in Visual Studio, you can also specify the configuration with the optional --config <config> flag.
The good part when using the cmake --build command is that it works for all generators (i.e. makefiles and Visual Studio) without needing different commands.
Afterwards I use the installed files to create packages or include them in other projects...
Starting with CMake 3.15, the correct way of achieving this would be using:
cmake --install <dir> --prefix "/usr"
Official Documentation
Starting with CMake 3.21 you can use the --install-prefix option instead of manually setting CMAKE_INSTALL_PREFIX.
The modern equivalent of configure --prefix=DIR && make all install would now be:
cmake -B build --install-prefix=DIR
cmake --build build
cmake --install build
Regarding Bruce Adams answer:
Your answer creates dangerous confusion. DESTDIR is intended for
installs out of the root tree. It allows one to see what would be
installed in the root tree if one did not specify DESTDIR.
PREFIX is the base directory upon which the real installation is
based.
For example, PREFIX=/usr/local indicates that the final destination
of a package is /usr/local. Using DESTDIR=$HOME will install the files
as if $HOME was the root (/). If, say DESTDIR, was /tmp/destdir, one
could see what 'make install' would affect. In that spirit, DESTDIR
should never affect the built objects.
A makefile segment to explain it:
install:
cp program $DESTDIR$PREFIX/bin/program
Programs must assume that PREFIX is the base directory of the final
(i.e. production) directory. The possibility of symlinking a program
installed in DESTDIR=/something only means that the program does not
access files based upon PREFIX as it would simply not work. cat(1)
is a program that (in its simplest form) can run from anywhere.
Here is an example that won't:
prog.pseudo.in:
open("#prefix#/share/prog.db")
...
prog:
sed -e "s/#prefix#/$PREFIX/" prog.pseudo.in > prog.pseudo
compile prog.pseudo
install:
cp prog $DESTDIR$PREFIX/bin/prog
cp prog.db $DESTDIR$PREFIX/share/prog.db
If you tried to run prog from elsewhere than $PREFIX/bin/prog,
prog.db would never be found as it is not in its expected location.
Finally, /etc/alternatives really does not work this way. There are
symlinks to programs installed in the root tree (e.g. vi -> /usr/bin/nvi,
vi -> /usr/bin/vim, etc.).
It is considered bad practice to invoke the actual build system (e.g. via the make command) if using CMake. It is highly recommended to do it like this:
Configure + Generation stages:
cmake -S foo -B _builds/foo/debug -G "Unix Makefiles" -D CMAKE_BUILD_TYPE:STRING=Debug -D CMAKE_DEBUG_POSTFIX:STRING=d -D CMAKE_INSTALL_PREFIX:PATH=/usr
Build and Install stages:
cmake --build _builds/foo/debug --config Debug --target install
When following this approach, the generator can be easily switched (e.g. -G Ninja for Ninja) without having to remember any generator-specific commands.
Note that the CMAKE_BUILD_TYPE variable is only used by single-config generators and the --config argument of the build command is only used by multi-config generators.
Lots of answer, but I figured I'd do a summary to properly group them and explain the differences.
First of all, you can define that prefix one of two ways: during configuration time, or when installing, and that's really up to your needs.
During configuration time
Two options:
cmake -S $src_dir -B $build_dir -D CMAKE_INSTALL_PREFIX=$install_dir
cmake -S $src_dir -B $build_dir --install-prefix=$install_dir # Since CMake 3.21
During install time
Advantage: no need to reconfigure if you want to change it.
Two options:
cmake DESTDIR=$install_dir --build $build_dir --target=install # Makefile only
cmake --install $build_dir --prefix=$install_dir