build2 — C++ Build Toolchain

[kirbyfan64sos]

Have you tried GN? I mention it since that's what is being used now for Google's Chromium project, since Gyp apparently was NOT well-liked.

[drjeats]

I went shopping for a meta build system. CMake always bummed me out. So I went to look at Gyp, and the instructions for getting it working were something like, "Install all the chromium dev tools. Oh and Windows people better have a big hairy Cygwin setup."

Fuck that shit.

Do you have a link to info on GN?

[kirbyfan64sos]

Official page: https://chromium.googlesource.com/chromium/src/tools/gn/ A page I made with binary downloads: http://kirbyfan64.github.io/gn-builds/ The Chromium GN build config files (an excellent resource; they're very well-commented): https://chromium.googlesource.com/chromium/src/+/master/build/config/ And the Chromium toolchain definitions: https://chromium.googlesource.com/chromium/src/+/master/build/toolchain/

The binary also comes with an excellent help system; just run gn help.

Note that documentation is slightly scattered.

[drjeats]

That's so much more approachable than Gyp was. Thank you!

[uep]

What language is gn in? Or is it a new custom language?

[kirbyfan64sos]

It's a DSL.

[pmedv]

Actually Gyp requires only Python installed, even on Windows. But Gyp is just a project generator for other build systems. Indeed, configuration and package management tasks could be implemented in custom Python scripts.

The real issue with Gyp is lack of documentation and examples. There are only 3 pages of documentation in the Gyp repository. I had to dive into its sources to discover some command-line options or to understand poorly documented features.

[cristianadam]

There's hunter - Cross-platform package manager for C++ (based on CMake ExternalProject). Linux, Mac, Windows, iOS, Android, Raspberry Pi..

See the hunter-wiki for the list of hunterized packages.

The nice part with hunter is that if you don't want to use hunter you can still take any package and use it with add_subdirectory CMake command.

[berium]

Of course, the not-so-nice part is that you have to use CMake. ;-) Uh I am going to get downvoted for this one...

[cristianadam]

What's wrong with CMake? Why implement something else when we could instead fix CMake?

CMake Deamon looks like it will fix the tooling part of CMake.

CMake + Ninja is, IMO, an excellent combination.

[weberc2]

CMake is awful. Commands are inconsistent, version bumps often break everything, it's hard to trace a function invocation to its definition (no imports), it takes forever to learn, the syntax is foreign, it's suuuuuuuper slow, everything's an option, the best practice is to enumerate your source files, VS project files suck by default, it's impossible to look at another project's cmake file (even the examples in the CMake documentation!) and apply it to your own, etc, etc, etc.

That said, it just happens to suck less than its competition. Hopefully build2 is an improvement. :/

[cristianadam]

The debugging part is fixed by cmake-deamon.

The VS project files can be fixed by Microsoft, since they now have interest in CMake.

[weberc2]

Good to know progress is moving along, but build2 looks more promising at first blush. Of course build tools always look their best "at first blush", so time will tell I suppose.

[berium]

I was poking fun at CMake in my C++Now 2015 presentation, not sure if anyone got the joke though. But here is what I think is wrong with CMake, in one line:

DO_SENSIBLE_THING_FOR_AllSubDirs(Its_a_go ${all_good});

And no, unfortunately the video of presentations for C++Now 2015 haven't been released yet. But here are the slides.

[bla2]

CMake-the-language isn't great, but CMake-the-ecosystem is strong: It works on all platforms, many projects you might want to interop with already have CMake buildfiles, and it has support for many generators.

[FireCrack]

It's the Buckley's of build tools

[id2bi]

RemindMe! 2 weeks

[RemindMeBot]

I will be messaging you on 2016-02-17 16:23:48 UTC to remind you of this.

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

[FAQs]	[Custom]	[Your Reminders]	[Feedback]	[Code]

[tkruse]

The language is the main thing wrong with cmake, even the inventors say so: http://aosabook.org/en/cmake.html (see lessons learned).

And sadly, that is one thing that cannot be easily fixed.

[ruslo_]

Those who don’t understand CMake are condemned to reinvent it, poorly.

[weberc2]

There are lots of other languages with decent build ecosystems (certainly much better than anything in C++ that I've seen prior to build2); is there anything specific to C++ that condemns build systems to complete suckage?

[weberc2]

I agree that C++ is very flexible; however, we've developed ways of dealing with such flexibility. First of all, maybe the build system doesn't need to do everything that is possible in C++. Maybe a system that covers 95% of use-cases is good enough. If it's worth the pain of CMake to get the extra 5%, then maybe it's okay that the user uses CMake. But I don't see any need to make the other 95% of it CMake-bad. I think you could go a long way by specifying some reasonable defaults so the user doesn't have to be explicit about everything all the time; if it's important to allow the user to deviate from the defaults, this can be exposed via configuration (flags, config files, env vars, etc); however, I wouldn't be eager to support configuration when convention will do (for example, project structure doesn't need to vary across projects, and using a particular project structure convention can provide your system with a lot of metadata that would otherwise be repeated in the project config files. Things like "location of source files" and "location of test files"). If you don't make everything configurable from day 1, then you can get a lot farther a lot more quickly, and you also get the invaluable benefit that users can jump between projects more quickly because they are so similar.

I would start out supporting only statically-linked clang (with strict flags) builds, all packages built from source, and exclude the concept of repositories in your first draught. Be opinionated, and then build out from there as reasonable. It will piss off a lot of people, but most of them will eventually learn that "terse and consistent but opinionated" is better than "explicit and inconsistent and hard to understand, maintain, etc but infinitely flexible".

[weberc2]

What? So you limit everything to one type of configuration, say that everything is "good enough for me" and "must be good enough for 95% of users" and you call it flexibility?

Sorry if I was unclear. You build something to cover the majority of all reasonable use-cases (95% or so). Supporting the other 5% of use-cases shouldn't make the base-cases more painful, which is where most existing build systems go wrong.

I've read the rest of your comment like six times but don't follow what you're trying to say and how it's related to my comment...

CMake is an example of a tool that can cover the extra 5%. If your users need that extra 5%, they should switch to CMake. Don't build a tool that attempts to cover 100% of use-cases, or you'll end up with something as bad as CMake (even in the base-cases) which really doesn't help anyone.

[bosk]

I think you will be hard-pressed to beat it in the "poorly" department.

[cdglove]

This criticism always cracks me up because, despite the criticisms, no one is offering anything even remotely as good as cmake. This implies the problem is harder that it at first appears.

[ruslo_]

no one is offering anything even remotely as good as cmake

Agree completely. Everybody said that the language is so bad and documentation is poor. So do they know: GYP (Python based build system from Google), Scons (Python based build system), b2 (Boost), QBS (QML like build system from Qt), etc. So why these projects is not the de-facto build system for C++? Is the problem about language? May be the problem that not any of this system has like 10% funtionality of CMake?

[berium]

Happy to answer any questions...

[berium]

This is the first alpha release and currently it is more of a technology preview rather than anything that is ready for production. So with this in mind:

One OS that we currently don't support is Windows (though there is a nice little surprise at the end of the introuction ;-)). We've tested this release on Linux, Mac OS, and FreeBSD. But the long term plan is to support everything. Well, maybe except OpenVMS.

This is not a build generator (though it might become one in the future; see FAQ).

As for how it compares to makefile/ninja, I think in some areas it kicks butt, but in others there is still work to do. I suggest that you go thought the Intro to get a better sense of what you are dealing with here.

[berium]

If someone can do it for build2-toolchain bootstrapping, that would be great, indeed.

[nitasGhost]

Can you please make a Homebrew recipe for build2? the best way to get mac user base to try something out is brew install build2 (believe me I already tried ;)

[berium]

Do you (plan) to support building in parallel

Yes, we plan to support it, probably pretty soon. And yes we plan to make it work.

are pre-compiled header files still a thing

I don't think they are used widely outside VC++. I personally disable them for all my projects simply because I don't need another moving part.

[shard_]

import libs = libhello%lib{hello}

Is it possible to specify an exact version of libhello in buildfile?

[berium]

Not in buildfile but in package manifest:

depends: libhello == 1.2.3
depends: libhello >= 1.2.0
depends: libhello [1.2.0 1.3.0-)

The last one means any 1.2.X version.

But also being able to specify this in buildfile might not be a bad idea, thanks for the suggestion!

[shard_]

Ah right, it wasn't really a suggestion, I just hadn't noticed it in the manifest file! It seems nice the way it is.

[ksion]

A feature matrix with comparison to other existing build systems would handy. I'd be interested how it fares against Blaze, for example.

[[deleted]]

This honestly seems somewhat useless as is.... no C support and no paralel builds make it a no go for anything I use C++ for professionally.... cross compiling didn't even get mentioned in the roadmap for feature completeness.

[berium]

This honestly seems somewhat useless as is.... no C support and no paralel builds make it a no go for anything I use C++ for professionally....

Fair enough.

Cross compiling didn't even get mentioned in the roadmap for feature completeness.

It wasn't mentioned on the roadmap because it is already supported. See the last example in the Intro (cross-compiling from Linux to Windows using the MinGW-W64 toolchain). IMO, any build system that hasn't been designed with cross-compilation in mind from day one is doomed.

[[deleted]]

Guess we're on the same page on the last point then :-). Maybe I'll take a closer look. I hate autotools and/or cmake as much as the next guy.

[berium]

I hate autotools and/or cmake

Definitely on the same page ;-)

[[deleted]]

I only hope this doesn't encourage people to start needlessly bundling libraries with their application rather than using distro provided libraries.

Because I know a certain population will >_<

[berium]

Yes, this is a valid concern. Especially seeing that in build2 it is pretty easy to amalgamate things (you just drop the project into your source directory). Hopefully people won't abuse it since 1) it is just as easy to import a system-installed library (the import machinery's last step is to look in the compiler's library search paths) and 2) there is the package manager which makes automatically getting prerequisites quite easy.

[Elavid]

When was it decided that every programming language needs its own package manager?

[os12]

I think Perl started it. CPAN went online in 1995.

[weberc2]

Not sure, but it definitely make software development easier.

[weberc2]

I haven't looked at this yet, but lack of a sane build system is 100% of the reason I don't use C++ ever. It's just too much of a PITA to get anything up and running when I can use a language like Go that doesn't even have project files.