4 ms·

I hear your statement about build problems as soon as someone does not use autoconf quite a bit. However, in the past I’ve had the opposite experience: Trying

by secure 14y ago

I hear your statement about build problems as soon as someone does not use autoconf quite a bit. 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. 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. Now let’s have a look at each of these: • NetBSD: No patches required to the makefiles: http://cvsweb.se.netbsd.org/cgi-bin/bsdweb.cgi/wip/i3/patches/ http://cvsweb.se.netbsd.org/cgi-bin/bsdweb.cgi/wip/i3/patche... • FreeBSD: No patches required to the makefiles: http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11-wm/i3/files/ http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11-wm/i3/files/ (they do their usual change to /usr/local in the ports Makefile) • OpenBSD: several patches because OpenBSD lacks SHM support, doesn’t want (?) to use pkg-config at compile-time and quite a few bugfix backports: http://www.openbsd.org/cgi-bin/cvsweb/ports/x11/i3/patches/ http://www.openbsd.org/cgi-bin/cvsweb/ports/x11/i3/patches/ I would argue that porting i3-wm to another platform is easy because you can understand the Makefiles and it’s very clear what they do. As a conclusion, I just wanted to show you that there are counter-examples to both: situations where autotools really does not do a good job and situations where you can deliver good Makefiles without using autotools at all.

takluyver 14y ago
This resonates with me. I've inherited an application recently that uses autoconf. Makefile.am files generate Makefile.in, which become Makefiles, which actually do the build. Then there's autogen.sh, configure.ac and acinclude.m4. If I want to change something in the build process, I don't have a clue where to start. The real kicker? It's a Python application, so there isn't much of a build process anyway. You can run it directly from source.
lmm 14y ago
>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).
- tedunangst 14y ago
  a) From the looks of things, "make CC=gcc-arm" should just work. b) It's an X11 window manager. It's not likely to compile with SUA, and I doubt any amount of autofucking is going to change that.
  - lmm 14y ago
    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)

by secure 14y ago

takluyver 14y ago

This resonates with me. I've inherited an application recently that uses autoconf. Makefile.am files generate Makefile.in, which become Makefiles, which actually do the build. Then there's autogen.sh, configure.ac and acinclude.m4. If I want to change something in the build process, I don't have a clue where to start. The real kicker? It's a Python application, so there isn't much of a build process anyway. You can run it directly from source.

lmm 14y ago

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

tedunangst 14y ago
a) From the looks of things, "make CC=gcc-arm" should just work. b) It's an X11 window manager. It's not likely to compile with SUA, and I doubt any amount of autofucking is going to change that.
- lmm 14y ago
  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)