I am trying to build the latest GNURadio package on my development system. Unfortunately this system configuration is tightly controlled and I can't just install new packages of software on it as it is used to develop a product and all development systems are kept in lockstep. We are currently on an older version of RedHat.
While I cannot modify the system includes I can download and use newer versions of packages locally (in non-system directories) as long as that doesn't affect the product build/debug environment. Normally this isn't a problem.
However, when building GNURadio I found that our development platforms use an older version of the Boost libraries than is required to build GNURadio. So, I got the latest version of Boost and extracted it into my local (home) directory. I found several directions for, I thought, instructing CMake to use additional include directories. Unfortunately, this hasn't seemed to work with the Boost libraries. CMake keeps complaining that it finds the older version of Boost and not the newer one I have extracted locally.
I have tried using
-DCMAKE_CXX_STANDARD_INCLUDE_DIRECTORIES=<dir>
and
-DCMAKE_CXX_STANDARD_INCLUDE_DIRECTORIES_BEFORE=<dir>
and this had no effect. I then tried adding the following to the top-level CMakeLists.txt file:
SET(CMAKE_INCLUDE_DIRECTORIES_BEFORE ON)
SET(CMAKE_CXX_STANDARD_INCLUDE_DIRECTORIES <dir>)
or, even
include_directories(BEFORE <dir>)
Again, no joy.
I did a bit of digging and found that there is a GrBoost.cmake module and it had an additional configuration for the boost directory so I added this:
list(PREPEND BOOST_LIBRARYDIR "<dir>")
to the top of the file. Again, no luck.
I've never used CMake before (and I'm not really keen on learning yet another build system if I don't have to - our company just switched to bazel and I am coming up to speed on that) so I am flying blind here.
What do I have to do to get CMake to look in my local directory to find the Boost stuff I downloaded?
Ok. As it often happens, just after asking the question I was able to find an answer.
It turns out that there is a command-line option to CMake (CMAKE_PREFIX_PATH=<dir>) where you can specify additional base paths to search for CMake config files. I just added this to the command-line and it was found just fine.
I wasn't even aware that Boost came with such config files. Live and learn.
#vre's comment would have probably worked just as well (maybe better, in fact).
I want to use KDL (Kinematics and Dynamics Library) in robot control box. But robot control box uses SCons as their build system while KDL uses CMake.
It turned out that the control box doesn't have CMake installed. Should I install CMake in the control box? Or write SCons file for compiling KDL?
====================================================
My question is ambiguous. Sorry for that. And unfortunately, I cannot show the link of Control Box, it's not public. Here is link of KDL installation manual.
http://www.orocos.org/kdl/installation-manual
Let me make it more clear.
Forget all of previous question above and all about Control box, KDL. Let's say that you want to use one library. But the library can be built using CMake according to installation manual. Your PC doesn't have CMake installed but it has SCons, and unfortunately you should not install CMake on your PC.
If you can only use SCons, what can you do?
I know this situation is not usual, I want to know your opinion.
To answer your initial question: Yes, you should always try to install CMake, if that is a build requirement for you library and if you need to build that library from the sources.
To answer your later question: Replacing or rewriting the build system scripts is a major effort and not advisable. In general there is no script to convert build-systems. Such script might help to make the manual transformation. If you have a look at LLVM's effort to replace Autotools by CMake or Boost replacing it's own build system by CMake, you find out it takes several people several years and still not everybody is satisfied.
Often you don't need to build the library yourself. Either there are already built packages from the project directly of from your distribution (Debian etc. packages) or third party packagers like Mac Ports or NuGet.
In your case KDL provides Debian/Ubuntu packages.
Additional KDL is part of ROS, which is experimental in Homebrew for OS X.
What I am looking for:
Download library
Extract It
Apply custom patch
Run configure
Run build command
What library I am trying to build are:
Openssl
Boost
Thrift
C-ares
Curl
Pcre
Nginx
ICU
JsonCPP
I think I can do these things using external module: http://cmake.org/cmake/help/v2.8.8/cmake.html#module:ExternalProject
But I have following question?
I have different type of build and with different directory. Is it
going to build all these library for every different target? If yes
it will be painful as all these library take one hour to build. Is
there a way I can control it and it only build it once. As library
remains same for all these targets.
On switching directory to different name. Cmake force everything to
be rebuild-ed. Will it be same for external library. If yes? How to
solve this problem. I don't want to rebuild the library if I am not
changing them and want to use them while switching to different
branches without building them.
Yes, you can use CMake's ExternalProject feature to accomplish what you want to do.
When using cross-compilation in combination with external projects, the source code will be built once for each toolchain. You could avoid rebuilds if you checked in the results of the build into a source-control system, and re-checked it out on each new person's machine, but I do not recommend this. Instead, have one of your "set up new computer" tasks actually be allowing the compilation to run overnight, which will also act as a test that the machine is actually usable. That set-up task can be launched by a system administrator prior to a new hire's arrival, or you can leave it to the new hire, as circumstances require.
I'm not completely certain what you are asking in your second question, but if the library is unchanged, CMake will detect that it is unchanged and not recompile it. Typically, the source code would be in a single directory tree: each compiled version would be built in a distinct location. Thus, developers can access any compiled version at any time just by switching directories. This is particularly helpful because it allows you to mount these directories over NFS to embedded hardware, et cetera.
I'm currently investigating cmake to allow automatic building on the Win32 platform. For all runtimes and libraries I'd like to build, Visual Studio (2008/2010) projects do allready exist.
I've come across cmake, but I'm unsure if I really need it. As the documentation says, cmake generates VS projects and they then can be built e.g. using MSBuild.
As the projects itself allready do exist (and build nicely via the IDE or MSBuild on the cmd line), what do I need and use cmake for? Just for directory/project folder traversal? Build failure reporting?
Regards,
Paul
Well, strictly speaking you do not need it. However, it does give you a few advantages:
The idiomatic way to use CMake, forces you to use out-of-source builds. Arguable, but I am personally convinced that these keep you source-repository very clean.
You can support multiple visual studio versions (with the out-of-source builds). Perhaps it will be a little easier to port your project to other compilers (from MinGW -> Linux GCC).
With the find_package and config.cmake files, and a large number of available findXXX modules, CMake makes it a lot easier to "import" third-party libraries into your build-chain.
You don't need it. Cmake is only useful if you are trying to keep the same source code able to build in multiple platforms and compilers. If you are simply building using the microsoft stack you have no need of it.
I have been looking for pros & cons of Autotools and CMake. But I would like to know opinions from people having used one (or both) of these tools for projects.
I used Autotools very basically a year ago and I know that one of the good points is that it relies on shell scripting, thus it does not need to be installed to be run and uses portable shell scripting. But it looks like it is too unix oriented, and it would not be possible to run the configure file on Windows.
I have now to choose a build system tool for an open source project that will have to be compiled for at least Linux & Windows. It is written in C++, and uses a Qt GUI front-end, the rest of it is "generic".
Thanks for you help.
Updated 16th of January 2019: Refined advice as tools evolve.
I have used autotools before for a considerable amount of time.
Currently I make intensive use of meson and cmake only when I need it.
Some personal advice:
for big teams, stick to CMake if you want to make use of the generators for XCode. If you do not need it, I would use Meson directly. Meson, as of version 0.49, also supports finding CMake configuration files (though I did not test yet how well this works). Also, Visual Studio seems to be sufficiently well-supported at this point in time, though, again, I did not try myself. The advantage of CMake is that it has Visual Studio integration.
Drop autotools. Meson covers well everything already. Their cross-compilation model is amazingly understandable. In CMake, last time I checked, everything was quite more difficult.
I have also tried scons, waf, and tup.
The most full-featured, cross-platform system, is CMake, but the DSL from meson will be easier to use for people used to python and others. Meson is starting to support VS also (a VS2015 generator) and some projects already have experimental support for it, for example gstreamer. Gstreamer is compiled in windows as well with meson. Right now there is VS2015 generator and VS2017 but I did not try myself the generators lately. As of meson 0.37.1 needed some work, but they are improving them and current version is already 0.40.
Meson
Pros:
The DSL does not get in the way at all. In fact, it is very nice and familiar, based in python.
Well-thought cross compilation support.
The objects are all strongly typed: you cannot make string substitution mistakes easily, since objects are entities such as 'depencency', 'include directory', etc.
It is very obviuos how to add a module for one of your tools.
Cross-compilation seems more straightforward to use.
Really well-thought. The designer and main writer of Meson knows what
he talks about very well when designing a build system.
Very, very fast, especially in incremental builds.
The documentation is 10 times better that what you can find in cmake. Go visit http://mesonbuild.com and you will find tutorial, howtos and a good reference. It is not perfect but it is really discoverable.
Cons:
Not as mature as CMake, though, I consider it already fully usable for C++.
Not so many modules available, though, gnome, qt and the common ones are already there.
Project generators: seems VS generator is not working that well as of now. CMake project generators are far more mature.
Has a python3 + ninja dependency.
Cmake
Pros:
Generates projects for many different IDEs. This is a very nice feature for teams.
Plays well with windows tools, unlike autotools.
Mature, almost de-facto standard.
Microsoft is working on CMake integration for Visual Studio.
Cons:
It does not follow any well known standard or guidelines.
No uninstall target.
The DSL is weird, when you start to do comparisons and such, and the strings vs list thing or escape chars, you will make many mistakes, I am pretty sure.
Cross compilation sucks.
Autotools
Pros:
Most powerful system for cross-compilation, IMHO.
The generated scripts don't need anything else than make, a shell and, if you need it to build, a compiler.
The command-line is really nice and consistent.
A standard in unix world, lots of docs.
Really powerful command-line: changing directories of installation, uninstall,
renaming binaries...
If you target unix, packaging sources with this tool is really convenient.
Cons:
It won't play well with microsoft tools. A real showstopper.
The learning curve is... well... But actually I can say that CMake was not that easy either.
The use of recursive make is pervasive in legacy projects. Automake supports non-recursive builds, but it's not a very widely used approach.
About the learning curve, there are two very good sources to learn from:
The website here
The book here
The first source will get you up and running faster. The book is a more in-depth discussion.
From Scons, waf and tup, Scons and tup are more like make. Waf is more like CMake and the autotools. I tried waf instead of cmake at first. I think it is overengineered in the sense that it has a full OOP API. The scripts didn't look short at all and it was really confusing for me the working directory stuff and related things. At the end, I found that autotools and CMake are a better choice. My favourite from these 3 build systems is tup.
Tup
Pros
Really correct.
Insanely fast. You should try it to believe it.
The scripting language relies on a very easy idea that can be understood in 10 minutes.
Cons
It does not have a full-featured config framework.
I couldn't find the way to make targets such as doc, since
they generate files I don't know of and they must be listed in the output before being generated, or at least, that's my conclusion for now. This was a really annoying limitation, if it is, since I am not sure.
All in all, the only things I am considering right now for new projects is are Cmake and Meson. When I have a chance I will try tup also, but it lacks the config framework, which means that it makes things more complex when you need all of that stuff. On the other hand, it is really fast.
I would not recommend autotools for Windows. Use CMake.
Why? Windows doesn't have a native sh.exe, and the emulation is slow. It's also very easy to get configury stuff wrong. I'm not saying it's impossible in CMake, but CMake surely abstracts more away, so you worry about less. CMake documentation can be a bit hard to read, but once it's set up, you should be fine for all toolchains ever supported by CMake. CMake also integrates testing, packaging etc...
Autotools is slow on Windows, does not work easily with MSVC, and has weird quirks with Windows (and other OSes) that are hard to debug, and hard to fix. libtool also sucks on Windows, where it often refuses to build a shared library even, if you think it should and could. Toolchain relocation issues are also prevalent with libtool, which may look at the wrong files in a user's toolchain. CMake is a lot easier in this regard. It assumes normal things about the target platform and creates generic and good build instructions.
Also, CMake has coloured output :) and nice progress percentages.
PS: I just have some experience with CMake and autotools on Windows as a user. CMake tends to work, autotools tends to bite your ear off when you're not looking, and smile at you when it fails due to some strange error...