
Show HN: Meson, a C build system - felipellrocha
https://github.com/mesonbuild/meson
======
jordigh
So... what does it do better than CMake and autotools?

Looks 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/](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.

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

~~~
felipellrocha
The tool might built in Python, but it doesn't really expose the python api to
the user, which (among other things) makes for super clean build files.

It's also very fast since it uses Ninja for the actual build phase.

~~~
dpc_pw
Ah, Ok. Thanks for clarification.

~~~
felipellrocha
Yeah, no problem. Here's a great video that gives an overview of the tool:
[https://www.youtube.com/watch?v=KPi0AuVpxLI](https://www.youtube.com/watch?v=KPi0AuVpxLI).

------
rtz12
Am I the only one who thinks make is fine for 80% of the things that these new
build systems popping out every day are trying to solve?

~~~
pekk
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.

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

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

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

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

