6 ms·

"Autotools is the worst form of build system, except for all those other forms that have been tried from time to time." -Churchill, probably In all seriousness

"Autotools is the worst form of build system, except for all those other forms that have been tried from time to time." -Churchill, probably In all seriousness, what's your preferred alternative? Seems like Autotools is a pain, but it gets the job done and is widely available. I haven't found a build system for C projects that is: - Less complicated - Available from default package repos so others who clone don't have to track down some esoteric package themselves - Free software that runs standalone on a shell, not in an IDE or whatever

DonHopkins 10y ago
As if I needed to build the latest version of Gnu cat on a Microvax.
heinrich5991 10y ago
You could try cmake. :) It also has better Windows support than autotools.
- mi100hael 10y ago
  > - Less complicated ;) cmake is actually exactly what I had in mind when I wrote that. Maybe I haven't used it enough, but I find it basically just trades Makefile.am everywhere for CMakeLists.txt everywhere.
mcguire 10y ago
There are two ways to do what autotools do. One is the autotools way. The other is the way every other similar tool does it (to my knowledge): the imake way. Autotools sucks. But everything else sucks more. There's a life lesson there, somewhere.
jff 10y ago
You should be able to build well-written code on a variety of modern systems using nothing more than a Makefile, or even just a shell script. See plan9port for an example of the latter.
- ori_b 10y ago
  Plan9port shops with, and uses, mk.
  - jff 10y ago
    You're right, but first the INSTALL script makes a few customizations based on what OS you're running (Solaris, OS X, Linux, *BSD), then bootstraps mk and finally runs mk on all the application source. The script takes into account differences in operating systems, without including thousands of lines of weird little leftovers from 30 years ago when you needed to check if you were actually running on a 16-bit Data General machine or whatever (I'm looking at you, autoconf)
tannhaeuser 10y ago
Like the quote says. Autotools sucks big time, and what it does has been largely unnecessary since around the turn of the millenium [1]; but since it's used almost everywhere in infrastructure (often decades-old) software you have to deal with it. If you pull a 927 and make a grand unified build system, you get something like CMake which sucks even more (its own build process takes longer than that of the software it's supposed to build, need to deal with C++, have fun with CMakeLists build errors and customizations, etc.). I believe git's build system is just a bunch of (or a single) Makefile. That's what an optimal build (but not mine, unfortunately) looks like. Though, pure (POSIX) make is insufficient for anything non-trivial IMHO. phk's famous rant on libtool: [1]: http://queue.acm.org/detail.cfm?id=2349257 http://queue.acm.org/detail.cfm?id=2349257

DonHopkins 10y ago

As if I needed to build the latest version of Gnu cat on a Microvax.

heinrich5991 10y ago

You could try cmake. :) It also has better Windows support than autotools.

mi100hael 10y ago
> - Less complicated ;) cmake is actually exactly what I had in mind when I wrote that. Maybe I haven't used it enough, but I find it basically just trades Makefile.am everywhere for CMakeLists.txt everywhere.

mcguire 10y ago

There are two ways to do what autotools do. One is the autotools way. The other is the way every other similar tool does it (to my knowledge): the imake way. Autotools sucks. But everything else sucks more. There's a life lesson there, somewhere.

jff 10y ago

You should be able to build well-written code on a variety of modern systems using nothing more than a Makefile, or even just a shell script. See plan9port for an example of the latter.

ori_b 10y ago
Plan9port shops with, and uses, mk.
- jff 10y ago
  You're right, but first the INSTALL script makes a few customizations based on what OS you're running (Solaris, OS X, Linux, *BSD), then bootstraps mk and finally runs mk on all the application source. The script takes into account differences in operating systems, without including thousands of lines of weird little leftovers from 30 years ago when you needed to check if you were actually running on a 16-bit Data General machine or whatever (I'm looking at you, autoconf)

tannhaeuser 10y ago

Like the quote says. Autotools sucks big time, and what it does has been largely unnecessary since around the turn of the millenium [1]; but since it's used almost everywhere in infrastructure (often decades-old) software you have to deal with it. If you pull a 927 and make a grand unified build system, you get something like CMake which sucks even more (its own build process takes longer than that of the software it's supposed to build, need to deal with C++, have fun with CMakeLists build errors and customizations, etc.). I believe git's build system is just a bunch of (or a single) Makefile. That's what an optimal build (but not mine, unfortunately) looks like. Though, pure (POSIX) make is insufficient for anything non-trivial IMHO. phk's famous rant on libtool: [1]: http://queue.acm.org/detail.cfm?id=2349257 http://queue.acm.org/detail.cfm?id=2349257