>However, in the past I’ve had the opposite experience: Trying to port software such as Apache, PHP or bacula to UNIX systems such as SGI IRIX, I always ended up writing a simple Makefile to compile the software instead of putting up with the multitude of autotools-fixing that would have been required. I reported one or two clear issues upstream and they have been fixed, but until the relevant fixes arrive at the projects (especially PHP came with an old version of autotools), some time will pass.
You know that you can replace config.guess and/or libtool with updated versions? Or run make -f Makefile.cvs to regenerate configure etc. from aclocal.m4?
And I would argue that the fact that you had the option of writing a Makefile is itself an advantage of autoconf, because it was written to generate Makefiles in exactly the kind of layering cruft that the OP is complaining about. A more "cathedrally" solution would probably have replaced Makefiles entirely, but by having autoconf generate them it makes it possible for people who know make to, in extremis, edit the generate files.
>As a counter-example, take i3-wm: it ships with a GNU Makefile (OK, multiple Makefiles in subdirectories, one for each tool) and compiles on Linux, Mac OS X, FreeBSD, OpenBSD, NetBSD.
Last time we had a post from the same guy I offered up two challenges: a) cross-compile the program for ARM, b) build the program on a version of SUA (the windows posix compatibility layer) that didn't even exist when the program was released. Both of these are things I can and have done trivially with autoconf-based builds; for most projects it requires no editing of files at all, just replacing config.guess with the latest version for challenge b. I'd be interested to see how building i3-wm was in those two cases (though not interested enough to go to the effort of actually doing it).
SUA comes with a perfectly good set of X11 client libraries. You can ssh into a windows box and run your window manager from there with no problems (other than why you'd want to)
You know that you can replace config.guess and/or libtool with updated versions? Or run make -f Makefile.cvs to regenerate configure etc. from aclocal.m4?
And I would argue that the fact that you had the option of writing a Makefile is itself an advantage of autoconf, because it was written to generate Makefiles in exactly the kind of layering cruft that the OP is complaining about. A more "cathedrally" solution would probably have replaced Makefiles entirely, but by having autoconf generate them it makes it possible for people who know make to, in extremis, edit the generate files.
>As a counter-example, take i3-wm: it ships with a GNU Makefile (OK, multiple Makefiles in subdirectories, one for each tool) and compiles on Linux, Mac OS X, FreeBSD, OpenBSD, NetBSD.
Last time we had a post from the same guy I offered up two challenges: a) cross-compile the program for ARM, b) build the program on a version of SUA (the windows posix compatibility layer) that didn't even exist when the program was released. Both of these are things I can and have done trivially with autoconf-based builds; for most projects it requires no editing of files at all, just replacing config.guess with the latest version for challenge b. I'd be interested to see how building i3-wm was in those two cases (though not interested enough to go to the effort of actually doing it).