C++ build systems [closed]
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this questionI will start a new C++ project (it may have some C components as well) soon and I am looking for a modern, industrial-strength (i.e. non-beta) build system. The software will be created by several developers in 3-5 years and will run on Linux (Mac OS X and Windows might be supported later). I am looking for something that has better comprehensibility, ease-of-use and maintainability than e.g. make but is still powerful enough to handle a complex project. Open source software is preferred.
I started looking into Boost.Build, CMake, Maven and SCons so far and liked features and concepts of all of those, but I'm lacking the experience to make a decision for a large project.
I don't have experience with the others, but if you're looking for a cross-platform, cross-toolchain build system, use CMake. CMake is not actually a build system, it's a build script generator - it generates the actual build scripts for a lot of build systems and (and that's in my opinion the strength) generates project files for major IDEs like Visual Studio and KDevelop. Recent KDevelop versions, by the way, have Intellisense for CMake files.
The generated build scripts or Visual Studio solutions are not as elegant as they would be if created manually, but since you also don't have to maintain them manually, it's fine.
The downside of CMake is that it doesn't really come with a lot of built-in tools, or an easy way to extend it (compared to e.g. MSBuild, which is of course just a build system, not a generator). Our Linux developers tend to call Unix command line tools to do things like compression/decompression, which are not available on a typical Windows installation, while in contrast MSBuild has thousands of additional commands available from community projects, so you don't need to use the command line, and it's really easy to create a new Task for MSBuild. I'm currently looking into how to get around these limitations for CMake, because it currently means we can't entirely build on Windows, even though the code itself would build fine.
Writing the CMake files is not a beautiful experience, but it's ok. The language has some strange quirks (like having to exactly repeat an if-condition in the else and endif, which will drive you crazy especially when experimenting), and you'll really, really hate having a file called CMakeLists.txt in each and every directory which has custom build rules (and that maybe a lot, in a large project), and they all show up just with the name in your IDE ;)
A few years into the future...
- SCons is dying off in popularity, from what I've seen. I don't like it at all.
- Waf is awesome (in my opinion). If you're looking into SCons, try Waf first. However, parallel builds always show you all the errors that occurred...so expect your screen to be flooded with error messages. Also, it can get a little complicated to extend.
- Boost.Build is one of my favorites but has the worst documentation on earth. Other than that, it's very flexible and lets you do almost anything. It can be a tad slow at times, though.
- CMake is good for only generating Ninja scripts; anything else is garbage (4000 lines of makefiles for a 1-source 1-executable project)
- Tup is nice, but it lacks anything for configuration.
- Autoconf is still autocrap.
Other ones not mentioned:
- Kbuild is a tad weird but looks nice. That's all I know.
- mk-configure is great for make lovers.
- Shake with shake-language-c is flexible and lets you do anything...if you know Haskell and don't mind abandoning VS support.
- Jamplus loves to shove
-m32at the end of every freaking compiler command, which sucks on a 64-bit system. - Tundra can be a tad repetitive but is still very fast and accurate.
- Bam...Tundra is better. It's fast without sacrificing accuracy.
- Gyp (used for Google Chrome/Chromium) is underdocumented but is a great alternative to CMake.
- Premake is great if you value simplicity, but it can get annoying when it comes do doing seemingly simple things.
- Bakefile is very restrictive but great for simple projects.
- fbuild is my favorite (along with Boost.Build). It's quite underdocumented but has plenty of examples and very readable source code. Build scripts are short, too. It's used to build (and was designed for) Felix. It's also very, very fast, and it's almost always perfectly accurate and has automatic parallelism that DOESN'T flood your screen. Ever. I'm using it to build a regex JIT engine and am very, very happy. It's also very easy to extend. However, it's still technically in beta, although I've never experienced any real problems.
I'd recommend fbuild or Boost.Build...or Gyp if you like makefile generators.
If you want to extend the basic functionality, definitely use fbuild. If you have LOTS of platform-specific flags/options and plenty of messes, use Boost.Build. If you need a makefile generator or have lots of configurations, try Gyp.
I've used SCons for over a year now and it's really cool. It's a full build system, not a build scripts generator.
It's Python based, and you write the SConstruct and SConscript (equivalent of Makefile) in Python which allows you to call any available library you may wish for and a much clearer syntax that what a Makefile authorize.
Since Python is crossplatform, so is SCons, no problem there.
It comes bundled with a good number of targets:
- detects the binary available and automatically maps a number of extensions toward the correct binaries
- detects the correct extensions for your objects/libraries depending on the OS, though you can override it
- provides facilities for common operations (to be delayed after the build) like Move, Copy, Tar, and you can provide your own python scripts and hook them
- works out of the box and yet provides many hooks of customization at every level
It's really efficient, and even proposes advanced features (like storing a hash of the preprocessed file in a sqlite db instead of using the timestamp) even though you decide of your strategy in the end.
It also offers dependencies cycle detection for free (something that definitely does not come with Makefiles) and the interface is generally just better / automated.
Did I say it was efficient ? Well it obviously allows for multiple jobs to be executed in parallel ;)
And it's also free, like in free drink, feel free to contribute ;)
I can only recommend it.
Also an other tool is TUP. My experiences are pretty good with this tool. Tup
- Handles dependencies automatically (no need to call gcc -M).
- Works with partial dependency graphs, therefore it is very fast.
- It supports recursive directory structures, in a brilliant way (Tuprules.tup)
- Supports git in an outstanding manner: Can create the .gitignore files automatically, based on the target list.
- Extremely easy to use and the syntax for the Tupfiles are very simple.
- It maintains a consistent build of the source files, even when you renamed a file, or deleted one. Therefore the built binaries are always reflecting the current state of the source. It also means, you never ever need to clean your project.
After using it for two quite complex projects I can say only a one bad thing about that:
- It is complicated to use together with ClearCase dynamic views.
I had a chance to compare all of them myself. First we've used make. It is ugly. You have to be make expert to really understand what's going on. I wouldn't take the pain ever again.
Then we moved to SCons. It's syntax is OK, you can still do ugly things because you can write your own scripts which tend to be programs. This gives you a lot of flexibility. But we kicked SCons because we had to wait for about 20 seconds for project scan and another 20 for build every time. Then my colleges wrote python code to cache it's scan results to files and almost doubled the performance. You still had to wait about 20sec for a build, when you've added a file or removed one from the project you had to rerun build with a --fill-cache parameter.
Then I've moved the project to CMake which is definitely my tool of choice. It's structure and syntax a very well readable and also documented. It generates you projects for almost every IDE and also early supports the new IDEs on the market. The build process is then as fast as your IDE and you only need to return to CMake when you add new projects or change project properties to stay with CMake
So I would suggest CMake
Take a look at Waf. It's a decent system that I use for most of my projects that's written in python and derived from Scons, Make and other systems of the like.
I have tried:
- scons <--- Too slow.
- waf <--- Pretty good, but overengineered in my opinion. Sometimes not easy to guess what to do.
- cmake <--- Not nice syntax, but pretty robust and quite fast.
- autotools (mythbuster docs) <--- Only unix. Best handling cross-compilation.
- tup <-- It is so fast and correct that it is unbelievable.
You are looking for industrial strength. I would say that scons is out, because it is too slow IMHO, even if it was nice. It does not have a config phase either.
waf looks good, but I found fighting how to do a few things, specially nested projects, in the correct way.
autotools is REALLY robust, though it is out if you want to support windows. Cross compilation is really robust in autotools.
CMake: I think you should go for this one. It is quite fast, it handles configuration just as autotools but works in windows, it generates projects for xcode, visual studio, make and more. This is a nice feature if you have a multi-platform project since you can generate the projects for the IDEs of choice. But I must say that I don't like the syntax too much. Anyway, it handles big projects well. I would go for cmake if I wanted an "industrial strength" solution. Even if I personally hate it a bit, it is the only viable option.
Tup: I think it is more unix-oriented. But I must say that for me it is the nicest one and it is insanely fast and simple. I love it. But what you need is cmake.
From what you mentioned, I've tried Maven - it's too strict, doesn't scale and is designed for Java, so I'd not consider it. I've also heard from people having used "Automake", which they jokingly call "Autobreak"
IMHO, the project with long life expectation shall prefer pure Make, GNU Make, to be precise. There are several powerful features of Make, normally not used, which help avoiding boilerplate code (e.g. use of eval/call, non recursive build). It's compatible with any other build system (e.g. in our projects we successfully combine it with Ant, used for Java builds). It has an excellent documentation, and is familiar to most developers.
From my experience it is always possible to isolate makesystem from the project to the extent that most project makefiles contain 2 lines: the name of the target and "include ${MKSYS_HOME}/makesystem.mk".
Another to look at is Bakefile.
Its main strength is taking a relatively simple input file (simple as XML gets, anyway) and putting out many different native build system files: Makefile.in on autoconf-based systems (Linux, OS X command line, BSD...), Visual C++ solution and project files, Xcode projects, MinGW and generic Unix Makefiles, etc.
That said, I don't know that I would use a system like this from the start. Since the initial target is Linux and the others are "maybes", consider starting with automake, and put the Bakefile (or whatever) move off until you do your porting. It's always a mistake to build things before you actually need them. There's always a tradeoff -- the Lowest Common Denominator Syndrome in this case -- and if you don't have to pay the penalty today, put it off until you do have to pay; you may never have to pay. If you go with automake and build your files sanely, the migration won't be too painful.
加载中,请稍侯......
精彩评论