Build tool - make vs?



My personal opinion would be to wait to merge since we’d have to maintain something that doesn’t quite work.

That said, I could be convinced otherwise. If I understood correctly, the only missing piece was the distribution tests? Why not have that piece just rely on the old make system to make it complete? Then I’d be happy switching over if it’s really going to cut down on work.


I believe that was the only thing missing but would want to go verify. That would actually be pretty cool!


I gave it a little more thought. Maybe the devs should beta test it for a while (rather than merging directly). The last thing I want is for it to fall short and require a lot of attention.



I’m OK with any version of cmake that will run everywhere we need it to run. I don’t think anyone else is objecting. We just need someone to do the port.

@seantalts had previously listed compatibility with IDEs as a desirable feature. And having something with better dependency structure than make. Something I could read would be a big plus. I can’t make heads or tails of what most of those symbols in our makefiles are doing, so I just sort of squint and hope for the best.


Yeah. I posted that particular page because 1) it’s exciting that there is now a best practices tutorial and 2) it has a bunch of “why good build system? why does that mean cmake?” that I find compelling that might be motivating, quoted here:

Why do I need a good build system?

Do any of the following apply to you?

  • You want to avoid hard-coding paths
  • You need to build a package on more than one computer
  • You want to use CI (continuous integration)
  • You need to support different OSs (maybe even just flavors of Unix)
  • You want to support multiple compilers
  • You want to use an IDE, but maybe not all of the time
  • You want to describe how your program is structured logically, not flags and commands
  • You want to use a library
  • You want to use tools, like Clang-Tidy, to help you code
  • You want to use a debugger

If so, you’ll benefit from a CMake-like build system.

Why must the answer be CMake?

Build systems is a hot topic. Of course there are many options. But even a really good one, or one that re-uses a familiar syntax, can’t come close to CMake. Why? Support. Every IDE supports CMake (or CMake supports that IDE). More packages use CMake than any other system. So, if you use a library that is designed to be included in your code, you have a choice: Make your own build system, or use one of of the provided ones, and that will almost always include CMake. And that will quickly be the common denominator if you include multiple projects. And, if you need a library that’s preinstalled, the chances of it having a find CMake script or config CMake script are excellent.


In the past, the only package based on cmake I ever succeeded in installing was Adol-C. Maybe it’s better now or maybe those build scripts were all buggy. It’ll be easy to convince me it’s a good idea if it works and either (a) the builds are easy to understand and modify or (b) it provides some functionality we don’t currently have like IDE support.


Por que no los dos? The other part of this link sort of addresses that:

Why use a Modern CMake?

Around CMake 2.6-2.8, CMake started taking over. It was in most of the package managers for Linux OS’s, and was being used in lots of packages.

Then Python 3 came out.

I know, this should have nothing whatsoever to do with CMake.

But it had a 3. And it followed 2. And it was a hard, ugly, transition that is still ongoing in some places, even today.

I believe that CMake 3 had the bad luck to follow Python 3.1 Even though every version of CMake is insanely backward compatible, the 3 series was treated as if it was something new. And so, you’ll find OS’s like CentOS7 with GCC 4.8, with almost-complete C++14 support, and CMake 2.8, which came out before C++11.

You really should at least use a version of CMake that came out after your compiler, since it needs to know compiler flags, etc, for that version. And, since CMake will dumb itself down to the minimum required version in your CMake file, installing a new CMake, even system wide, is pretty safe. You should at least install it locally. It’s easy (1-2 lines in many cases), and you’ll find that 5 minutes of work will save you hundreds of lines and hours of CMakeLists.txt writing, and will be much easier to maintain in the long run.

This book tries to solve the problem of the poor examples and best practices that you’ll find proliferating the web.



Not CMake 2.8 though; that was released before C++11 even existed! Nor the horrible examples out there for CMake (even those posted on KitWare’s own tutorials list). I’m talking about Modern CMake. CMake 3.1+, maybe even CMake 3.12+! It’s clean, powerful, and elegant, so you can spend most of your time coding, not adding lines to an unreadable, unmaintainable Make (Or CMake 2) file. And CMake 3.11+ is supposed to be significantly faster, as well!


I think we should just go ahead and do this, as long as:

  • it won’t mess up CRAN

  • it won’t mess up PyPI

We also need to make sure we can

  • replace existing functionality with CMake and Python

I don’t think the changes need to happen all at once. Can we have an incremental plan to get there? The scope of the changes has always defeated this project in the past.

We’re going to have to keep dumping resources into maintaining make until we have a working CMake for at least some part of the process as we can’t stop things like GPUs and MPI just because we don’t like the existing make system.


Modern CMake looks cool. One thing the docs don’t cover is dependency management. I don’t see how that could be done without doing it the way we’re doing it with make: calling the C++ compiler to generate it for us.

Hopefully it’s a lot simpler to maintain. Before going too far, can someone check that they can actually install a good minimum version across all 3 operating systems? If we can’t get it reasonably installed on Windows, it’s a different level of effort (maintaining two independent build systems instead of one).


I think it might be a good idea to actually have both at the same time while we transition, the way Github did with rails:

Looks like cmake has Windows binaries and an installer: