I'm using Yocto and struggling to update cmake. The poky version that we are using provides cmake version 3.3.1, but one of the packages that I'm building requires cmake version 3.5 or greater.
Looking at the poky git repo, the latest provides version 3.8.2. I figured that the easiest way to upgrade cmake was to include the recipes for cmake from the current poky master branch within my own meta repo, in order to override the lesser version. So I copied the cmake directory, and expected the build to continue along...
Unfortunately, the cmake recipes that I copied in aren't working. The recipes won't even load, as they throw an error, saying "docker must contain prefix as its prefix." Printing the output of the prefix and docdir variables to the console, I see that docdir is set to "${datadir}/doc" -- the datadir variable is not expanded.
In summary, the questions that I have are:
What is the best way to upgrade cmake? Is the best way to copy in the updated recipes into my own meta repo?
Why isn't the datadir variable being expanded, and how can I fix that?
What is probably happening is that the recipe for cmake 3.8.2 (2.4) is not backward compatible with the poky version from 3.3.1 (Version 1.9). The reference is here. I guess some refactoring and important milestones happened meanwhile
The easiest way is to upgrade the whole poky folder in your ecosystem, hoping it is not breaking your other recipes.
Related
The project, I am currently working on, is based on another open source project foo. CMake allows me to easily include this project into my build system:
...
add_subdirectory(foo)
...
I need to make some changes to foo, but I do not want to touch the originakl project. More precisely, there are a couple of source files of foo that require minor changes to remain compatible with my project. Is there a possibility in CMake to load the original project and then to patch it with my changes?
Some sources refer to cmake -E, but I could not find a documentation. Is this what I am looking for or what other solutions do exist?
You can use ExternalProject module
Clone the upstream repo. Add your patch and use this repo (as a Git submodule or with the CMake module above). Add upstream remote and get changes from upstream from time to time. Or (the best) convince the maintainers to include your patch to upstream version ;)
I'm missing something in my understanding of CMake+vcpkg, and I'm also missing proper keywords to search for a solution. (Plus I'm new to both CMake and vcpkg, unfortunately.)
I want to have a public repo for a C++ project that uses CMake as its build system and vcpkg as its package manager.
At my currently level of understanding the user needs to have CMake and vcpkg already installed before he can type cmake and build the repo. I'd like to make it as simple as possible to build the repo and not have a bunch of instructions telling him how to get set up even before he can build.
Is this right?
I'd like a one-step solution: After cloning the repo user types ... something ... and the repo gets built.
I am willing in this day-and-age to assume he's got CMake installed ... plus that it can find the right toolchain. So maybe all he needs to type is 'cmake' ...
Is it a reasonable assumption that the user has CMake installed and configured with his preferred toolchain?
I am not willing to assume he's got vcpkg installed.
Is it a reasonable assumption that the user does not have vcpkg installed and configured?
(TBH, I don't even know if it is CMake or vcpkg that configures the toolchain - I assumed CMake but one of the suggested questions suggests it is vcpkg ...)
What are the reasonable assumptions today, and what is the minimal-step solution?
There's nothing wrong in assuming that the user has certain tools installed.
Let's say you are developing libfoo which depends on libbar and you want to make it as easy as possible for your users to install libfoo.
With a package manager
If libfoo and libbar are available via the same package manager all your users have to do is:
vcpkg install libbar libfoo
You don't have to do anything special in libfoo for this, just instruct the user to install all dependencies in your readme.
It doesn't really matter what package manager is used.
Without a package manager
You will still want to make it easy for people to build and install your project directly. It may seem that invoking a package manager during the build or configuration phase of your project and solving all dependencies is user friendly because the user no longer has to deal with installing those, but it isn't for a number of reasons, including:
you or someone else may want to add your project to another package manager (like conan, spack, etc)
someone may want to consume libfoo with FetchContent, CPM, directly with add_subdirectory, etc
someone may not be a user of vcpkg - there's no need to force them to use it, if possible
you may want to add another dependency, libbaz, which is not available on vcpkg
a user may have the right version of libbar already installed (not necessarily through vcpkg)
This list is not exhaustive. If you're not writing a library some points don't really apply.
This means that someone who has all the dependencies already installed should be able to use libfoo like this:
git clone your-repo
cd your-repo
cmake -Bbuild
cmake --build build
cmake --install build
Resolving dependencies without a package manager
However, it may be desirable to solve dependencies automatically. If your dependencies are using CMake the easiest way of doing this is with FetchContent. For some of the reasons outlined above you should provide an escape hatch so people can still use the already installed dependencies. This can be done with an option. For example, something like FOO_USE_EXTERNAL_BAR. This can be set either to yes or no by default, there's no right answer. As long as the user can control this I don't think it matters that much. You should namespace your options to avoid possible conflicts with options used by other projects.
In this case your build script could do this:
if (FOO_USE_EXTERNAL_BAR)
find_package(bar REQUIRED)
else ()
FetchContent_Declare(
bar
GIT_REPOSITORY bar-repo
GIT_TAG release-tag
)
FetchContent_MakeAvailable(bar)
endif ()
target_link_libraries(foo PRIVATE bar::bar)
Depending on how libbar's CMakeLists.txt is written and organized the if and else branches may get more complicated. See Effective CMake for some details and tips.
Now I can either let libfoo resolve the libbar by setting FOO_USE_EXTERNAL_BAR to ON when I configure your project, or I can set it to OFF to have more control over how it is resolved. I may even use libfoo as a dependency for a project that already depends on libbar. If you always pull it in I can't avoid conflicts in this case.
Using CMake to update dependencies
You may still find it easy for you to be able to update all the project's dependencies using CMake without downloading them via FetchContent. While this will probably raise some eyebrows you could add a custom target for solving dependencies with a package manager. This should also be controllable by an option. Unlike in the above case I strongly believe that if you do this the option should be set to off by default:
if (FOO_AUTO_USE_VCPKG)
add_custom_target(
update_deps
COMMAND vcpkg install libbar
)
add_dependencies(foo update_deps)
endif ()
This will invoke vcpkg every time you build foo so it will make your builds slower. If you remove the add_dependencies call you would have to manually run the update_deps target whenever you need to (which shouldn't be that often anyway).
Notes
Using options is a great way of providing options to your users. It should be noted that they increase the cognitive load, so picking strong defaults can help with that.
FetchContent is a nice way of taking the care away from the user, but at the same time multiple projects that use it will end up re-downloading the same libraries over and over again. It is still more user friendly than invoking a package manager at build time and as long as the users can disable this behavior there's nothing to worry about.
Some parts of this answer may be regarded more as opinion and less as facts. As I said, there is no one right way of doing this, different people will have different ways of solving this problem. Different projects and different environments will have different constraints.
I already recommended the Effective CMake talk above, other useful recourses are available here. If you're a library author you may also want to take a look at Deep CMake for Library Authors.
I had this same question. For my part, I am not willing to assume that the user has either CMake or vcpkg preinstalled.
Here is my solution so far, as a Windows batch file:
#REM Bootstrap...
set VCKPG_PARENT_DIR=C:\Projects
set CMAKE_VERSION="3.20.2"
mkdir "%VCKPG_PARENT_DIR%"
pushd "%VCKPG_PARENT_DIR%"
git clone https://github.com/Microsoft/vcpkg.git
.\vcpkg\bootstrap-vcpkg.bat -disableMetrics
set PATH=%PATH%;%VCKPG_PARENT_DIR%\vcpkg\downloads\tools\cmake-%CMAKE_VERSION%-windows\cmake-%CMAKE_VERSION%-windows-i386\bin
set VCPKG_DEFAULT_TRIPLET=x64-windows
set PYTHONHOME=%VCKPG_PARENT_DIR%\vcpkg\packages\python3_x64-windows\tools\python3
popd
#REM Build the project...
cmake -B build -S .\engine\ -DCMAKE_TOOLCHAIN_FILE=%VCPKG_ROOT%\scripts\buildsystems\vcpkg.cmake -DCMAKE_BUILD_TYPE=Release -DUSE_PYTHON_3=ON
cmake --build .\build\ --config Release
mkdir bin
xcopy .\build\Release\*.* .\bin\
xcopy .\build\objconv\Release\*.* .\bin\
xcopy .\build\setup\Release\*.* .\bin\
It could use some improvement, but hopefully this gives you an idea of one route you could take.
I'm trying to have my recipe be compiled and linked against the arm libraries. I'm using cmake. I can't seem to figure out the right work flow, after having read trough multiple documents on the yocto site and reference materials. My approach right now is:
Set the source
Build my target minal image, without the layer that I want to use
Try to build my specific recipe: bitbake Test
I have downloaded the arm toolchain from the Yocto site, and prepared it in my sources/poky. Here I can see the systroots and all the libraries that I would need. My recipe bb file is the following:
# This file was derived from the 'Hello World!' example recipe in the
# Yocto Project Development Manual.
#
SUMMARY = "Project"
SECTION = "examples"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
SRC_URI = "file://."
S = "${WORKDIR}/project/src"
inherit pkgconfig cmake externalsrc
And my CMake file contains, among more:
link_directories(/media/traffic/Yocto/QorIQ-SDK-V2.0-20160527-yocto/sources/poky/sysroots/aarch64-poky-linux/usr/lib)
I'm able to compile a hello world project fine, but as soon as external libraries take a role, it goes wrong.
cannot find /usr/lib/libpthread_nonshared.a
/media/traffic/Yocto/QorIQ-SDK-V2.0-20160527-yocto/build_ls2084abluebox/tmp/sysroots/x86_64-linux/usr/bin/aarch64-fsl-linux/../../libexec/aarch64-fsl-linux/gcc/aarch64-fsl-linux/4.9.3/ld: cannot find /usr/lib/libpthread_nonshared.a
It seems to look in the wrong folder. Are the steps that I'm taking correctly? Or am i missing something?
Elmar
Which poky version are you using? I got exactly the same issue recently with another package. There are 2 issues here:
It cannot find the pThread library. I added a FindThreads.cmake in the tree and imported it. But then the linker could not make it. I went to the conclusion, cmake itself had an issue with this library and ended changing the poky commit to have a different version of CMake. Note that you can also keep the new poky versions and have the custom CMake in your layer.
CMake 3.7 and 3.8.2 were not working properly but the 3.7.1 was for me (hash c9a512b6408d4cc11c1b36f7bc1b9b1c31056ce1). To find out which commit, you can execute
git log --pretty=oneline | grep cmake:
I am working on a project that uses CMake. The top CMakeLists.txt file contains the following line:
cmake_minimum_required(VERSION 3.7.2) # Kittens will die if you switch to an earlier version of CMake. We suggest using CMake 3.8.0.
I want to force all developers to switch to CMake 3.8.0, but for some reasons, not all developers have administration rights and are not able to switch from 3.7.2 to 3.8.0 immediately. Actually, we do not need any new features of version 3.8.0, but our policy is to use always the newest and greatest tools to prevent "porting up" problems in the future - for instance switching fast from Qt4 to Qt5 was a good decission in the past - I know switching always to the newest libraries and tools has also some drawbacks as discussed here, but we want to do it this way.
Because of this, instead of forcing everyone to use version 3.8.0, I'd like to output a warning message if CMake 3.7.2 is used. Somehow like this:
# not working - just pseudocode
if(CMAKE_VERSION == "3.7.2")
message("Please consider to switch to CMake 3.8.0")
endif()
I tried to read the VERSION variable, but this does not work. Does anyone now how this check can be achieved?
There exist a few variables for that, described here:
CMAKE_MAJOR_VERSION
major version number for CMake, e.g. the "2" in CMake 2.4.3
CMAKE_MINOR_VERSION
minor version number for CMake, e.g. the "4" in CMake 2.4.3
CMAKE_PATCH_VERSION
patch version number for CMake, e.g. the "3" in CMake 2.4.3
Also, the variable CMAKE_VERSION contains the string for the version.
In your case, you would, for instance, use the following:
if(${CMAKE_VERSION} VERSION_LESS "3.8.0")
message("Please consider to switch to CMake 3.8.0")
endif()
Other comparison operators are VERSION_EQUAL and VERSION_GREATER.
Am using ubuntu 16 which seems automatically linking against Eigen version 3.2.92 located at /usr/include/Eigen3. I would like to link against version 3.2.0. Thus my questions is
How could I get Eigen version 3.2.0? It is not clear from Eigen website
What I did so far is just copying /usr/include/Eigen3 from an ubuntu 14 machine, since the latter automatically comes with version 3.2.0
How to link against it using CMake?
Tried
SET (EIGEN3_INCLUDE_DIR "/home/usr/mylib/eigen/eigen3/Eigen") but without success.
For info, am using ROS (Kinetic) catkin. It happens that catkin somehow forces the development packages to linking/compiling against packages installed by default (/usr/include/..)
Other versions of Eigen are available on the website or better, from the hg repo.
How is the EIGEN3_INCLUDE_DIR used in your cmake file? For example, in one of my projects, we have set(EIGEN_INCLUDE_DIR ${SOURCE_DIR}/Common). Note that it doesn't have the "3" (it's just a variable name) and that it doesn't include the last "/Eigen" in the path.
First of all, Eigen is a header-only library, so you are not linking against it :-) Instead you want to use specific header files.
For your own packages, you can use include_directories(SYSTEM ${EIGEN3_INCLUDE_DIR}, assuming you set EIGEN3_INCLUDE_DIR correspondingly to the version you want to use. Beware that if that version differs too much (e.g. 2.x vs 3.x) with versions used by interfaces (e.g. tf library?), this may cause some issues if datatypes changed. You also need to make sure that no other directive overwrites that - best to check the parameters to g++ for that.