CppCon 2018: Peter Bindels “Build Systems: a Simple Solution to a Complicated Problem”

—
—
New developers starting out with C++ nearly universally hit a brick wall - it's very hard to start programming and get something working. Unlike other languages such as Java, NodeJS, Rust and Python, where a standard package manager and build system take care of these problems for you, C++ has all the ability and variation under the sun to create nearly anything - if you've understood how to make the tools do what you want them to.

Things don't need to be so complicated. Nearly always, the things you're making aren't as complicated as the tools allow you to express. There is a good reason why C++ build systems are so complicated though, but it's not one that requires them to be. In this talk we'll explore the design space for build tools (with a focus on C++) and discover a simpler way of building software.
—
Peter Bindels, TomTom
Principal Software Engineer

Peter is a C++ developer known for writing HippoMocks and cpp-dependencies, and less well known for encouraging C++ both for beginners and for uncommon target areas (OS development, embedded, server-side). He likes to rethink the basics of what we take for granted to see if new ideas emerge, and to see where previously-old ideas are now new discoveries.
—
*-----*

[jonskunator]

It's good that this stuff is discussed. It sometimes feels that in addition to writing the software, maintaining the build system becomes a separate project of its own. This is a clear problem of modern times. There's a lot of this stuff that could be made to "just work". Meson is a breathe of fresh air in this sense. But there's still a lot of work to do. Many issues become highlighted when you pick an arbitrary open source project so that you can make changes to it, and you spend a full day tinkering to just get the build system all set for that project.

[aaardvaaark]

Awesome talk and awesome project, thanks for your work. The complexity surrounding getting something built is I'm sure what scares more would-be c++ programmers away than learning the language itself.

[jhbonarius]

Hey peter! Leuk om je daar te zien. Groeten, Jochem.

[mapron]

5:12 cmake is not a make implementation (and so do Qmake) :) Even it's not "an alternative" to make like ymake e.g., it can generate Makefiles. Just want to be precise.

[mjKlaim]

I think there is an issue with the live presentation (left part of the screen), it seems to not be in sync with the rest of audio + video (on the right).

[irshadbasheer]

I would say every build systems is a complicated solution to simple problem

[OperationDarkside]

Now a Visual Studio Code Plugin and I'd be a happy camper

[xavierthomas]

I love the idea. My main concern is, because I an mot that good of a coder, I need all the help my IDE (QTCreator) can provide: completion, refactoring, clang-format, cpp-check, ... How does that work with evoke? Given it uses Cmake under the hood and QTCreator supports CMake, I suppose it should work to some extend, but every time I add a new file I would have to re-run evoke and rerun CMake in some way.

[yoyonel]

Hi ! Which version of boost do you use to build evoke please?

[zvxcvxcz]

There may be over 20 make implementations... but they are not equally popular. Cmake is not a simplification, it's a higher level abstraction, which almost universally means simpler only with the major caveat that you never look under the hood. How long can "doing nothing" really take make that Ninja could be all that much faster?

Build systems seem to do a whole lot of nonsense that doesn't, and shouldn't be part of a build system. Release notes should be handwritten, all automation is not good simply by being automated. The number of times I've seen totally useless and uninformative release notes.... How about writing decent documentation instead of automated bullshit? I know some programmers say they don't need it, or don't read it, or that it is out of date (who's fault is that after all? their own) and think auto generated type lists of functions somehow counts as documentation.

What I want my build system to do:
1) compile and link my code on every hardware platform, none of this other nonsense.
Procedural is not hard to get right, if you can't get that right on at least one platform, then you have no hope of getting any of the other ones correct.

Evoke looks nice, but I guess my concern would be if it would ever be ubiquitous enough to use for deploying to embedded and stuff like that. Or at least across a few more of the major OSs. It may have grown since the talk, I realize it is a few years old now. This seems to automate the things that should be automated while leaving the things that shouldn't alone, I should try it out.

[mytech]

I like the notion but I thinl it hides too much from a new user. This will seem easy to a beginner or very knowledgable user but will create many learning obstacles getting users through the transition from beginner to expert.

This black box will inevitably cause many new coders to form an incorrect mental model of the process and then that model becaomes a source of error and frustration to further advancement.
I see this with many subjects not only computer science, teachers of children often excessivly simplify introductions to a topic and a few years later the student has major difficulty transitioning to more advanced concepts because their underlying foundation is inaccurate.
I see it a lot with developers that start with fully managed IDEs and languages, there is a huge number of intermediate developers that think the IDE is the language and compiler/interpreter with no idea what is really happening.

Although your approach could work if it generated a summary for the user to confirm the specific files, steps, and details that will be used for the build (Maybe optional with a command flag, but recommend the flag in documentation and all starter tutorials). This would be especially suitable IF the student can combine it with a good instructor that can start by teaching the fully manual approach using a text editor and manual compilation, library handling[all types], testing, linking, and packaging of some example projects.
Unfortunately most introductions only go as far as Hello World, maybe a header file, and single step compilation to a stand-alone executable; without ever mentioning all of the other major build options let alone a proper introduction to using them.

[llothar]

Nice idea and i did almost the same as this guy but i'm far ahead of him. Seriously, no toolchain switching no android, maybe no ios .... sorry next year maybe. But i'm now going to read the pitchfork.