1
votes

I happen to think (but maybe is a myth) that Cmake is greater than Autotools about making easy supporting Microsoft.

At the same time, I'm kind of sure that Autotools is even more straightforward than Cmake when it comes to important UNIX derivatives such as macOS and most popular Linux distros.

What if I can't choose?

Can a project support both Autotools and Cmake at the same time?

Bonus for: can a project support both Autotools and Cmake and even simply bare Make at the same time?

By "at the same time" I mean that ideally one should not necessarily run a clean script when changing from trying one of the build systems to another. But I guess it would be a reasonable configuration, if necessary.

Finally, do you know an example project that uses both Autotools and Cmake? One that uses both Autotools, Cmake and simply bare Make?

1
"can a project support both Autotools and Cmake and even simply bare Make at the same time?" - Sure, why not? You just need to write corresponded scripts for each tool.Tsyvarev
GNU uCommon C++ framework is an example of a codebase that supports both autotools and cmake.Woodrow Barlow
i would also agree that cmake is more windows-friendly iff you are targeting visual studio with MSVC on windows. if you're targeting msys, mingw, or cygwin with gcc on windows... ehhhh. at that point it just comes down to preference. beware how you pull in dependencies, though, because cmake on windows does not come with pkgconfig, meaning "find_package" probably won't work.Woodrow Barlow

1 Answers

3
votes

Yes, you can very easily support both CMake and Autotools at the same time, since they don't overlap (that is, the files you use to create those environments are different, so you can have both types of files in your project at the same time). One example of this is the GNU uCommon C++ framework.

No, you can't (easily) support bare make and either of the above systems at the same time. Neither Autotools nor CMake are actually build tools themselves. They're "build tool generators". So you don't run autotools or cmake and the result is your built project: instead you run autotools or cmake and they generate control files for a build tool. Then you run the build tool and the result is your built project.

Autotools generates makefiles, and cmake generates many different types of control files, where makefiles are one of the most common.

So, you can't have your OWN makefile in your project, because they'll conflict with the makefile generated by autotools or cmake.

Of course, you can do things like put your own makefiles in a subdirectory then invoke make with an argument like make -f rawmake/makefile or something like that. But there's no convenient way to support them all.

Realistically, I would never choose to support more than one of the above options. You will spend a lot of time getting it right, and every time you need to change your build environment it's two or three times as much work. People will find issues with whichever one of them you tend to use less often. It's a huge hassle for not that much benefit.

Which you choose depends a lot on your project. If your project runs only (or almost exclusively) on POSIX-type systems, you want it to be maximally portable even to much older systems even though it uses a lot of special OS features, or you want its installation and build options to be extremely flexible (straightforward support for cross-compilation, etc.) then autotools is a good choice. If your project runs on lots of different OS types (Windows in particular) and you want people to be able to develop with their choice of IDE (Visual Studio, Xcode, etc.) easily, then cmake is a good choice.

If your program is straightforward to build and needs hardly any configuration or customization, or you are already familiar with makefiles and don't feel like learning a whole new language just for builds, then raw makefiles may be a good choice.