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

[@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.

[@robinmoussu]

This is just simply awesome!

[@mapron1]

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).

[@dascandy]

The demo part is a re-recording due to technical issues with the live demo. I've tried to keep it close but sadly it is not quite exact.

[@mjKlaim]

@@dascandy Ah I was wondering if it was a re-recording because there was some differences. Ok!

[@irshadbasheer749]

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

[@dascandy]

Working on it :-) - just created an issue to track it on the github.

[@OperationDarkside]

@@dascandy Thank you, because last time I tried to add a dependency(PostgreSQL C++ wrapper) to my project, I needed 2h to get it running.

[@dascandy]

@@OperationDarkside I've added basic VSCode support so it can now run your builds from inside VSCode. There's also a doc/VSCode.md explaining it in a bit more detail. Let me know if this is what you meant or open a new issue if you want it to do more / integrate more.

[@OperationDarkside]

@@dascandy I just tried it on an ubuntu. But I needed to compile the whole of boost library, because the one provided by ubuntu was too old it seems. And when I compiled I got an error "PendingCommand.cpp undefined reference to boost::system::detail::system_category_instance". It is a little ironic, that to compile a build system, to make my dependencies easier, I have a dependency problem(or I just made a beginner mistake). I know it is a lot to ask, but could you make it dependency free?

[@xavierthomas1980]

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.

[@dascandy]

If you want what CMake does, you can use cpp-dependencies (github.com/tomtom-international/cpp-dependencies) which can auto-generate cmakelists in the same way that Evoke can run your build. And yes, that would be a manual step... which is why I made Evoke, so I can have it all in one go. Ideally I would like it to integrate more tightly with your IDE; running as a background service or so. You should be able, given a smart enough IDE, to use it just as a background build tool, either run on-demand or continually, right now.

[@alexreinking]

Even if you are an expert coder, IDEs provide a lot of value...

[@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.

[@dascandy]

> 1) compile and link my code on every hardware platform, none of this other nonsense. That is exactly how I still see it. The rest could be done in a build-system style syntax, but there's no benefit to it, and many downsides. Evoke works well enough to build for embedded, kernel work etc. Conceptually it hasn't changed much since the talk; importing of packages has been improved, multiple toolchains can be built at the same time, it can run in a daemon mode automatically rebuilding whenever something changes etc. For myself it's my daily driver build system for anything I create.

[@yoyonel1808]

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

[@dascandy]

I've built it with the current version of boost on Ubuntu 18.04 and 18.10; it's not very picky. It uses boost.filesystem only in it's v3 incarnation, so I think any Boost since 2014 or so should be fine. I'll soon add an option to use std::filesystem to it if available.

[@dascandy]

Minor addition - the process invocation was switched to use Boost.Process, which requires Boost 1.64 now. For further updates, see the Evoke github readme.

[@mytech6779]

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.

[@dascandy]

Thanks for the detailed response, even 5 years after the talk. I completely agree that it should be transparent in what it does, and should expose all that information to the user. At the same time, it *should* all be obvious / implicit, so I don't want to bore / annoy the user with it. Right now there's a `-v` flag to ask it to output all the steps it plans to take, the dependencies it knows and the results of build steps, but I do recognize that it's both too verbose (too much output) and too hard to understand. Do you have suggestions how to better visualise it? You seem to have a great grasp of the problem. Particularly, how to make it clearer on a command-line...

[@llothar68]

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.

[@dascandy]

You're funny. What about telling people about your project, showing it and letting them try it out?

[@llothar68]

@@dascandy Because it's not portable as it is tight to my own directory structure and workflow. I'm just telling this to trash his project as too small too early to make anyone interested in this project.

[@dascandy]

@@llothar68 " I'm just telling this to trash his project as too small too early to make anyone interested in this project." This sounds like you're actively trying to be harmful to somebody who's trying to help the world. Am I misreading this?

[@llothar68]

@@dascandy Too many bogus projects are not helping the world but making it worse.

[@zvxcvxcz]

@@llothar68 ... How is yours "far ahead" if it isn't portable and is super specific to your directory structure and workflow? That seems like you just have a procedural approach to build your project that is useless to everyone else...