> installing into a DESTDIR

> setting custom CFLAGS/LDFLAGS

> changing prefix, libdir, sysconfdir

> cross-compilation

Pretty much all of this can be done trivially in a makefile, using a very innovative construct called "variables".

> parallel builds

make -j. Works especially well if you have working dependencies. This makefile does.

> conditional features

make has ifdef... Granted this makefile uses find to discover source files, which won't totally work. But it's a small fix. Or you can do conditional features through CFLAGS.

Can be done. The question is will the half-assed Makefile that a developer wrote for themselves do any of those things? And I can tell you from bitter experience that is very very unlikely. Plus I will still have to spend the time to understand the Makefile, which I won't need to do if they'd used an established build system in the first place.

We can agree that half assed makefiles are bad. I don't believe in throwing out the tool on that basis. If that were the bar, we might as well not write any software in any language with any tool.

I imagine most projects will never leave the hard drive they're first written to. Writing a basic "half-assed" makefile that works for the initial author is fine. If a project turns out useful, rewrite the makefile as people need the compatibility. There's little point in wasting the time when you're just starting out.

There’s no point telling people not to do something if you don’t give them an alternative that does do all those things.

(And no, “just use autotools” is not a viable answer.)

Autotools does do all of those things. I'm not a particular fan of it either, but when I'm packaging software for a Linux distro then I'd rather see autotools or cmake being used instead of some crappy custom build system that will require patching to make it work.

There is room for someone to come up with a good build system. It had better do everything autotools and cmake do, and be well documented and widely used, so there's a rather large barrier to entry.

Whenever "configure" is looking for a fortran compiler in a clearly non-fortran program, one has to wonder why no one fixes the configure scripts. From all I learned it is, because the underlying scripts are close to unmaintainable. So from that perspective, a better build tooling should be a high priority.

No one fixes the configure scripts because they're thousands of lines of code in about three different archaic languages that nobody knows or cares about.

Fix configure.ac, not configure which is effectively a binary.

Auto tools is great. To compile all you do is

    ./configure
      make
      make install

It couldn't be simpler. Even though I am part of the GitHub generation, I don't see why so many of my peers hate it. I actually like it.

This is kinda hilarious because, yes, "Autotools is great" [as a consumer]. But autotools and m4 is kinda awful to write IMO.

... and autotools is actively hate-inducing if you have to debug it.

autotools is pretty great for the end-user who wants to compile your code or the distributor who wants to package it up for Debian or whatever.

It’s a crawling horror for the programmer that wants to use autotools as the build solution for their code however, which is the topic under discussion.

This only works in the Unix world, on Mac only for command line tools (but only after installing autoconf and make), and not at all on Windows unless you install a complete Unix environment (cygwin or mingw).

Why would it only work with command line programs on the Mac? That's definitely not true, unless something changed very recently.

Also, you don't need autotools itself to build a autotoolized program. The generated configure script is portable sh.

Not really. the end user doesn't need autotools installed actually. To build the configure script from the "configure.in" file, you need autotools. Go ahead and try!

That's the ideal situation, yes, but god help you when something goes wrong.

It's not that hard. I recently had to debug a memcached configure.in script. But, I consider myself a C programmer, so that fact might be source of bias.

>And no, “just use autotools” is not a viable answer.

After packaging hundreds of programs for a GNU/Linux distro and dealing with handwritten Makefiles and other so-called autotools replacements: Yes, it is.

If you want someone to be able to build and install your software, just use the Autotools. Yup, they are ugly, but they're still the only set of tools that works acceptably.

Not only that, but every time I'm up against a problem building software that uses something else, it's like, "oh great now I have to figure out what their secret badly-documented variable names are and how to configure their XML/JSON/YAML/whatever"

It's a pleasure when autotools is used because in generally I know it's going to be nothing much more than

> --with-stuff/--without-stuff

and

> --prefix=$HOME/.local

and when it's not, at least I know I can just grep the shell script and figure it out pretty quickly without having to learn a whole new programming language.

I'm surprised no one says, "Just use waf."

It does all those things. It's fast. It's cross-platform. The language is Python.

It's a bit steep to learn and maybe doesn't have the most mature built-in recipes for certain complex builds like mobile or desktop frameworks, but it seems like those things would be addressed quickly if more people were using it. The maintainer is a class act, consistently putting out new features and bug fixes and working with pull requests.

WAF is not so much a build system, but a bunch of python scripts to create your own build system, it's in the same zoo as cmake, scons or premake, but (in my opion) worse than any of those. I might have had a bad first impression though because of the project I had to use WAF in had terribly complex WAF scripts.

True, they do call it a build system toolkit. But I think worse than the others is on the wrong track and the sentiment is too heavily influenced by your negative first impression.

swtoolkit made scons really nice to work with (but couldn't fix the speed issues). It's a shame it was abandoned. In the same way, a thin layer of functions as demonstrated in the waf "toolkit" examples could lean on the power of waf and provide a build system every bit as snazzy as big, polished systems like bazel and buck, but it would work cross-platform out of the box and be extensible with only Python. But I think waf is close enough to being high level that no one bothers to create and polish a build system layer (maybe internally in companies, but the open source uses I've seen use pretty standard waf scripts).

Ehm ehm... every second reply around here is shouting "cmake"...

CMake is icky. I’ve never been comfortable with it. I’ll take hand written makefiles over CMake, unless I have to have Windows as a build target.

The LibreOffice build system (which is plain GNU Make, without generated unreadable intermediate build files) does all these and more. Doing the same with autotools would be a nightmare.

We do however have some serious gnu make gurus to make that tractable.

... as we would have needed for CMake or Autotools. It might have worked with the former for something as complex as LibreOffice, but GNU make being so simple/basic and stable over the years was a big plus: Im sure even with CMake LibreOffice would have had fun with lots of small cornercase regressions.