I know how to link GDAL with a C++ application using CMake. The procedure is summarized hereafter in two steps: (1) Installing the dependency on the system and (2) linking it to the C++ application (see here for more details).
Install GDAL (here on Ubuntu 18.04)
Add the PPA to the sources: sudo add-apt-repository ppa:ubuntugis/ubuntugis-unstable
Update: sudo apt-get update
Install GDAL and its development files: sudo apt-get install gdal-bin libgdal-dev
Test the installation: gdalinfo --version
Link GDAL with the C++ application using CMake:
# find system installed GDAL package with predefined CMake variable for finding GDAL
find_package(GDAL REQUIRED)
...
# Specify location of GDAL header files
include_directories( include ${GDAL_INCLUDE_DIRS})
...
# Specify GDAL libraries to link your cpp executable target against
target_link_libraries( your_cpp_executable_target_name ${GDAL_LIBRARIES})
What is the most convenient way to avoid the user to perform the manual installation of the dependency? That is, how to ensure that the missing dependency will not stop the configuration, and download/build the dependency if not found on the system?
For managing the Boost dependency, I used the CMake ExternalProject feature with a Superbuild pattern, and I think a similar approach should be relevant for managing GDAL dependency. However, I am very new at modern CMake, and I struggle adapting this CMake project handling the Boost dependency to also manage a GDAL dependency.
Any general or step-by-step directions to help doing (or good reasons not to do so) would be helpful.
Related
I need to build a C++ program with CMake but it cannot find Boost.
I'm getting the following error no matter what solutions I've found online for other people with this problem...
-- Compiling with C++ standard: 17
CMake Error at /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find Boost (missing: Boost_INCLUDE_DIR) (Required is at least
version "1.68.0")
Call Stack (most recent call first):
/usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake-3.22/Modules/FindBoost.cmake:2360 (find_package_handle_standard_args)
CMakeLists.txt:49 (find_package)
This is the part of my CMakeLists.txt looking for Boost
if(NUMCPP_NO_USE_BOOST)
target_compile_definitions(${ALL_INTERFACE_TARGET} INTERFACE -DNUMCPP_NO_USE_BOOST)
else()
find_package(Boost 1.68.0 REQUIRED)
target_link_libraries(${ALL_INTERFACE_TARGET} INTERFACE Boost::boost)
endif()
I have installed boost with sudo apt-get install libboost-all-dev and a few other apt-get options. I always see 0 upgraded, 0 newly installed, 0 to remove after running.
$ whereis boost
boost: /usr/include/boost
Do I need to specify it in the cmake .. line in the terminal somehow?
Assuming that you've successfully installed boost in the default directory, and CMake has access to those directories, probably the problem (as #drescherjm mentioned) is in the version of the Boost you've installed (sometimes the packages provided by apt-get are relatively old).
On the other hand it can also be that CMake doesn't have the installation directory in its search path.
The following steps might be a good place to start:
Check the version of the Boost installed: How to determine the Boost version on a system? and here
If the version installed by apt-get satisfies the project requirement, it seems for some reason CMake didn't include a directory of installation to its searching path. If that's the case, skip to the step 3.
If it's lower than your project requires, build it from source (right now 1.80 is available) to your preferred directory. If you need the libraries which need to be built, check this tutorial.
Tell CMake where to search for built Boost. See here: Cmake doesn't find Boost
I hope this reply is not too off-topic. I suggest you consider using a package manager such as conan or vcpkg.
An example of using conan to use external dependencies.
1. Create conanfile.txt
It should have the following content:
[requires]
boost/1.80
[generators]
CMakeDeps
CMakeToolchain
2. Download your dependencies
mkdir build && cd build
conan install .. --build=missing
conan build ..
The last command is optional and can be changed with:
cmake -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake ..
Benefits:
You don't need to "mess" your system with different libraries
Transitional dependencies are handled automatically
The build process is reproducible
I'm pulling in Boost using CPM to build another dependency of my project.
CPMAddPackage(
NAME Boost
VERSION 1.77.0
GITHUB_REPOSITORY "boostorg/boost"
GIT_TAG "boost-1.77.0"
)
The issue I'm having is exposing the header files to my dependency. I dumped all of the cmake variables, and there are many variables like boost_accumulators_SOURCE_DIR, boost_algorithm_SOURCE_DIR, boost_any_SOURCE_DIR, boost_asio_SOURCE_DIR, etc. My dependency depends on many of these libraries, and it's really tedious to list them all as include directories:
target_include_directories(
nghttp2_asio
PRIVATE "${boost_system_SOURCE_DIR}/include"
PRIVATE "${boost_config_SOURCE_DIR}/include"
PRIVATE "${boost_asio_SOURCE_DIR}/include"
PRIVATE "${boost_throw_exception_SOURCE_DIR}/include"
PRIVATE "${boost_assert_SOURCE_DIR}/include"
PRIVATE "${BoostAlign_SOURCE_DIR}/include"
PRIVATE "${boost_date_time_SOURCE_DIR}/include"
)
Is there a better way to do this?
CPM is just a thin layer around FetchContent, which in turn downloads your dependency into your build folder and then attempts to add_subdirectory it, adding it to your main build.
I think this is a bad idea for a lot of reasons...
Boost is one of the most commonly packaged C++ libraries, period. Integrating your project into an existing environment (like a Linux distro, or another package manager like Conan or Vcpkg) is going to be difficult if not impossible (without patching, I mean) since it will surely want your project to use the curated build of Boost.
Adding any third party CMake code to your own build is signing up for headaches... have you noticed how hard it is to write correct CMake code? What if Boost clobbers your cache variables or defines targets that conflict with yours?
CMake has built-in and standard support for locating many versions of Boost, including the newer versions that provide first-party CMake config modules.
Boost now provides first-party CMake config modules.
I don't think any build using Boost should be any more complex than this:
cmake_minimum_required(VERSION 3.22)
project(boost-usage-example)
find_package(Boost 1.77 REQUIRED system date_time)
add_executable(nghttp2_asio main.cpp ...)
target_link_libraries(
nghttp2_asio
PRIVATE
Boost::boost # all header-only libs: config asio throw_exception assert align
Boost::date_time
Boost::system
)
See the documentation here: https://cmake.org/cmake/help/latest/module/FindBoost.html
You only list as components (after REQUIRED) the non-header-only libraries. Those are also the ones that require special addition via target_link_libraries. Link to Boost::boost to get all the header-only modules.
This will work no matter what package manager you're using.
If you want to use vcpkg, create a file called vcpkg.json in your project root with the following contents:
{
"name": "boost-usage-example",
"version-string": "0.1.0-dev",
"dependencies": [
"boost-system",
"boost-config",
"boost-asio",
"boost-throw-exception",
"boost-assert",
"boost-align",
"boost-date-time"
]
}
You can also depend on just boost and it will acquire all boost modules, not just the ones you need. Then acquire vcpkg:
$ git clone https://github.com/microsoft/vcpkg.git
$ ./vcpkg/bootstrap-vcpkg.sh
Then build with:
$ cmake -S . -B build -DCMAKE_TOOLCHAIN_FILE=$PWD/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_BUILD_TYPE=Release
$ cmake --build build
Done!
Suppose on the other hand that you wanted to use Conan. No big deal, just install Conan in a pip virtual environment:
$ python3 -m venv venv
$ . venv/bin/activate
$ python3 -m pip install -U pip setuptools wheel
$ python3 -m pip install conan
Then create a conanfile.txt with the following contents:
[requires]
boost/1.77.0
[generators]
cmake_paths
Install the dependencies:
$ mkdir build && pushd build && conan install .. && popd
And then build, using Conan's generated toolchain file:
$ cmake -S . -B build -DCMAKE_TOOLCHAIN_FILE=$PWD/build/conan_paths.cmake -DCMAKE_BUILD_TYPE=Release
$ cmake --build build
In fact, you can provide both a vcpkg.json and a conanfile.txt and your users will be free to use either one or neither and rely on their system package manager or a package manager you don't know about. In any case it will just work and you free yourself of a mountain of maintenance burdens.
I'm working on c++ project on a linux machine and it uses several boost libraries. I've installed them on my system using vcpkg and build it using the toolchain provided by vcpkg. My question is:
How do I define the dependencies so that they automatically install on a different system, if they were to build it?
Conan has a way of doing it by defining the dependencies in conanfile.txt. How do I do the same with vcpkg?
Edit1: I've found autovcpkg which does the job I'm looking to do but can the same be done natively inside cmakelists.txt or by vcpkg itself?
If you have vcpkg as a submodule for your project, define a manifest for the libraries you want vcpkg to build, and are using the vcpkg CMake toolchain - then you will get everything you want.
Adding vcpkg as a submodule means that your users don't need to install it themselves, the CMake toolchain will install it on your behalf. It also means that you can fix the package versions
Using a manifest file is how you programmatically tell vcpkg which packages to get and build during a CMake configuration phase
Using a CMake toolchain file is the only way to tie this into your project's build system
$ git clone .../my_project
$ cd ./my_project
$ git submodule update --init
$ mkdir ../build
$ cd ../build
$ cmake ../my_project
-- Running vcpkg install
-- Running vcpkg install - done
...
I've found autovcpkg which does the job I'm looking to do but can the same be done natively inside cmakelists.txt or by vcpkg itself?
You can write a vcpkg port for your library or executable by providing a CONTROL and portfile.cmake file. In the CONTROL file you define all the dependencies and possible features while the portfile contains the build instruction. You can use vcpkg create <myport> <url> <filename> to create the CONTROL and portfile.cmake from a template which can be customized to your needs.
Together with a port-overlay this port can also be used by others without being merged into vcpkg/master
The library I am trying to include is jsoncpp. I am having serious trouble with this. I used the home-brew install for this library, which is brew install jsoncpp (brew install is unix version of linux sudo-apt get). Normally homebrew installs stuff to my path, so I can just use it. I am going off of this example here.
#include <json/json.h>
Returns an error of 10: fatal error: 'json/value.h' file not found.
I am using cmake because CLion automatically sets it up. Right now it is very basic:
#CMakeLists.txt
cmake_minimum_required(VERSION 3.13)
project(Read_JSON)
set(CMAKE_CXX_STANDARD 17)
add_executable(Read_JSON main.cpp)
However, for some reason jsoncpp cannot be found. How can I include this library in my project?
You can use in CMake FetchContent capability.
Jsoncpp is available via git repository on GitHub
Here is example how I made with googletest:
https://github.com/adamvm/hello/blob/master/CMakeLists.txt
You need just substitute proper addresses and names
On mac install with command.
brew install osrf/simulation/ignition-fuel-tools2
In Ubuntu (since 18.04) you need to install libjsoncpp-dev[1] package:
sudo apt install libjsoncpp-dev
[1] https://packages.ubuntu.com/search?keywords=libjsoncpp-dev
I'm trying to compile a software from source codes. In one compiling stage, I need to navigate the directory which holds CppUnit Libraries (e.g. /home/user/lib) and CppUnit Includes (e.g. /home/user/include). How can I install these CppUnits and navigate them into ubuntu 14.04?
sudo apt-get install libcppunit-dev
This command installs library and headers.