At a glance, I don't see how it solves the problem that autotools solves: test for features, not for versions. Not sure if that's a problem people are trying to solve anymore. Instead, everyone is required to have the latest version of everything at all times to build, I suppose, and building older versions is never supported.
Once in my careerer I was already tasked with stripping a C project from a Python based building system (SCons, IIRC) because it was damn slow, buggy, and problems with Python and SCons were more severe than with a C codebase itself. I replaced it with kbuild, and it still works nicely in production even today.
I'm hesitant getting anything Python-related next to my C codebase, and IMO, C-people are generally not very enthusiastic about Python. Once the time comes, that something custom needs to be done in the building system, dealing with Python syntax, completely new abstractions, etc. is just more pain than using established solutions that everyone are familiar with (make, autotools, CMake).
Maybe Python 3 ecosystem (things like packaging etc.) does not suck as much as Python 2 (though I'd bet it still does), and maybe Meson is really great, but on top of my Python-implementation reservations, I also don't see much of a point: the billions of C legacy code will not be ported to a new building system, a there should be not that much new projects in raw C anyway, with languages like Go, Rust, D showing clear road ahead, baking their own solutions for common building system issues. Projects like "tup" have much more appeal to my C-developer nature, but then again, I didn't have opportunity to employ tup anywhere, as nowadays I write every new project in Rust.
Than again, it's just my personal opinion, and I guess somewhere, some people could find it really fitting their needs.
I write and work on several different C-based and C++-based projects. For the last 2 projects I decided to use scons. I find scons much easier to work with than other build tools that I've used. Our projects aren't huge (30k - 50k LOC), so perhaps we just haven't reached some threshold at which scons gets bogged down. I'm curious about the bugs you encountered in scons. It's been very stable and hassle-free for us.
Make is fine for small projects. But as soon as your have something more complex in your hands, automating all of that stuff can be a huge productivity saver...
The problem with `make` (and all build systems that generate `Makefiles` for `make`) is both flexibility and correctness. Correctness problems:
* Make cannot correctly specify file system state dependencies (like inexistence of files, such as include files in include paths prior to the found location).
* Make doesn't protect against accidental edits of source code while it is being built, poisoning the result files. When you try to run "make" again, it will say nothing is to be done, but the result file [with its newer mtime] can actually be based the pre-save source file.
* Make uses < and > for mtime checks (not just ==) and that is incorrect on some operating systems (e.g: Windows).
* Make offers no practical way to track or enforce system-level dependency changes.
* Easily miss stderr printouts from compilers/etc, if you missed them at the first time around (losing mainly gcc/clang warnings)
The "solution" is almost always to "make clean" whenever voodoo bugs are encountered, anything system-level is changed, etc. This is terrible if you expect correctness from your tools.
Flexibility-wise, make is also awful, due to one huge problem:
Make requires the dependency graph to be fully specified, including all transitive dependencies. This makes code generation a near impossibility -- since you often need to scan the generated code to figure out its dependencies.
IOW: Make is a "two-phase" build system, where we really want an "N-phase" build system that interleaves building with dependency scanning/discovery.
Also, this is taken for granted, but it is major: Make requires error-prone specification of all file dependencies. This is impractical to do correctly in large, complex projects. Every script being run may have tons of transitive dependencies that are very hard to specify. Any mistake will usually go unnoticed, until you hit a "voodoo bug" and just "make clean".
Additionally, make doesn't support any form of advanced caching of previous build results.
---
All these problems, and more, made me decide to create my own build system for our complex C project: buildsome[1].
It uses file system hooking to provide both correctness (no more missed input dependencies!) and simplicity (no need to specify each and every transitive dependency, they can be automatically discovered).
It checks input files for changes after the build commands (to avoid output file poisoning). It remembers stderr and re-prints it. It supports N-phase builds. And more.
By the time you are reaching for recursive make, if you can't just get rid of the complexity with a rethink, it's probably better to use something different.
I personally prefer auto tools because learning it has value. Learning auto tools has value because a lot of C projects use auto tools, so contributing to C projects is easier if you know the de facto standard build system for GNU/Linux based C projects.
A build system for C. The build system isn't the problematic part, it's the C part. I'm sure we can figure out how to compile code faster than it is currently, but without a comprehensive module and ABI versioning standard we won't make building large systems easier.
From my perspective, CMake has pretty much become the standard build system for C/C++ projects that need to be compiled on more than one platform. That was not the case a few years ago, but I'm seeing it more and more often. Maybe people realized that while it's not perfect and has some weird behaviors, it's the most practical tool to do the job right now.
I watched the Linux.conf.au 2015 video to get a more detailed overview of meson. I think the most interesting feature is that it at least partially tries to address the problem of building library dependencies, although I don't get the impression that was an emphasis.
In particular, the tup build system didn't get mentioned at all, which I find surprising, since IMHO it has broken new ground in build speed, correctness, and ergonomics. I think it hasn't gone viral because it doesn't try to solve most of the language specific problems people are starting to expect build systems to solve. It also doesn't have a very good story for the build specification language, IMHO.
I think a bigger issue in build systems is that the open source ecosystem does NOT have a tree structure; you have a big rats nest of dependencies on specific versions because everything is constantly changing. I think we need something like nix, but that is fully distributed, and perhaps piggybacking on git databases (and ssh trust networks) to distribute binary dependencies along with the source.
I watched the Linux.conf.au 2015 video to get a more detailed overview of meson. I think the most interesting feature is that it at least partially tries to address the problem of building library dependencies, although I don't get the impression that was an emphasis.
In particular, the tup build system didn't get mentioned at all, which I find surprising, since IMHO it has broken new ground in build speed, correctness, and ergonomics. I think it hasn't gone viral because it doesn't try to solve most of the language specific problems people are starting to expect build systems to solve. It also doesn't have a very good story for the build specification language, IMHO.
I think a bigger issue in build systems is that the open source ecosystem does NOT have a tree structure; you have a big rats nest of dependencies on specific versions because everything is constantly changing. I think we need something like nix, but that is fully distributed, and perhaps piggybacking on git databases (and ssh trust networks) to distribute binary dependencies along with the source.
19 comments
[ 2.9 ms ] story [ 52.7 ms ] threadLooks like the answers can be found here, which would be a more pertinent link. Can we change the original github link to this?
http://mesonbuild.com/
At a glance, I don't see how it solves the problem that autotools solves: test for features, not for versions. Not sure if that's a problem people are trying to solve anymore. Instead, everyone is required to have the latest version of everything at all times to build, I suppose, and building older versions is never supported.
I'm hesitant getting anything Python-related next to my C codebase, and IMO, C-people are generally not very enthusiastic about Python. Once the time comes, that something custom needs to be done in the building system, dealing with Python syntax, completely new abstractions, etc. is just more pain than using established solutions that everyone are familiar with (make, autotools, CMake).
Maybe Python 3 ecosystem (things like packaging etc.) does not suck as much as Python 2 (though I'd bet it still does), and maybe Meson is really great, but on top of my Python-implementation reservations, I also don't see much of a point: the billions of C legacy code will not be ported to a new building system, a there should be not that much new projects in raw C anyway, with languages like Go, Rust, D showing clear road ahead, baking their own solutions for common building system issues. Projects like "tup" have much more appeal to my C-developer nature, but then again, I didn't have opportunity to employ tup anywhere, as nowadays I write every new project in Rust.
Than again, it's just my personal opinion, and I guess somewhere, some people could find it really fitting their needs.
It's also very fast since it uses Ninja for the actual build phase.
Python was written in C, by C people.
* Make cannot correctly specify file system state dependencies (like inexistence of files, such as include files in include paths prior to the found location).
* Make doesn't protect against accidental edits of source code while it is being built, poisoning the result files. When you try to run "make" again, it will say nothing is to be done, but the result file [with its newer mtime] can actually be based the pre-save source file.
* Make uses < and > for mtime checks (not just ==) and that is incorrect on some operating systems (e.g: Windows).
* Make offers no practical way to track or enforce system-level dependency changes.
* Easily miss stderr printouts from compilers/etc, if you missed them at the first time around (losing mainly gcc/clang warnings)
The "solution" is almost always to "make clean" whenever voodoo bugs are encountered, anything system-level is changed, etc. This is terrible if you expect correctness from your tools.
Flexibility-wise, make is also awful, due to one huge problem:
Make requires the dependency graph to be fully specified, including all transitive dependencies. This makes code generation a near impossibility -- since you often need to scan the generated code to figure out its dependencies.
IOW: Make is a "two-phase" build system, where we really want an "N-phase" build system that interleaves building with dependency scanning/discovery.
Also, this is taken for granted, but it is major: Make requires error-prone specification of all file dependencies. This is impractical to do correctly in large, complex projects. Every script being run may have tons of transitive dependencies that are very hard to specify. Any mistake will usually go unnoticed, until you hit a "voodoo bug" and just "make clean".
Additionally, make doesn't support any form of advanced caching of previous build results.
---
All these problems, and more, made me decide to create my own build system for our complex C project: buildsome[1].
It uses file system hooking to provide both correctness (no more missed input dependencies!) and simplicity (no need to specify each and every transitive dependency, they can be automatically discovered).
It checks input files for changes after the build commands (to avoid output file poisoning). It remembers stderr and re-prints it. It supports N-phase builds. And more.
[1] https://github.com/ElastiLotem/buildsome
Take, for example, a line from my current makefile: LEFTPAREN:=(
It took me lots of studying the manual, googling and stackoverflowing to arrive at that "solution".
Because there is no way to quote a left paren. There simply isn't. And I'm grateful at least this stupid workaround is possible.
In particular, the tup build system didn't get mentioned at all, which I find surprising, since IMHO it has broken new ground in build speed, correctness, and ergonomics. I think it hasn't gone viral because it doesn't try to solve most of the language specific problems people are starting to expect build systems to solve. It also doesn't have a very good story for the build specification language, IMHO.
I think a bigger issue in build systems is that the open source ecosystem does NOT have a tree structure; you have a big rats nest of dependencies on specific versions because everything is constantly changing. I think we need something like nix, but that is fully distributed, and perhaps piggybacking on git databases (and ssh trust networks) to distribute binary dependencies along with the source.
In particular, the tup build system didn't get mentioned at all, which I find surprising, since IMHO it has broken new ground in build speed, correctness, and ergonomics. I think it hasn't gone viral because it doesn't try to solve most of the language specific problems people are starting to expect build systems to solve. It also doesn't have a very good story for the build specification language, IMHO.
I think a bigger issue in build systems is that the open source ecosystem does NOT have a tree structure; you have a big rats nest of dependencies on specific versions because everything is constantly changing. I think we need something like nix, but that is fully distributed, and perhaps piggybacking on git databases (and ssh trust networks) to distribute binary dependencies along with the source.