4 ms·

How much easier does autoconf make things, really? I think the key phenomenon here is that software is non-portable by default, and portable through effort. I

How much easier does autoconf make things, really? I think the key phenomenon here is that software is non-portable by default, and portable through effort. If your problem is that the Linux code should use epoll() and the BSD code should use kqueue(), but OS X has quirks in its kqueue() implementation, and you need to fall back to poll() otherwise, autoconf will help... slightly. Then you need Sys V init scripts, or rc scripts, or launchd scripts, or... who even knows, unless you actually convince someone to port your project to that system. So, you already have people testing and fixing bugs on other platforms, but now you tell them that they need to also learn M4 so they can write an Autoconf macro to test for some... thing... that you need which doesn't have a standard test. I'm not convinced that this makes my life any better. Whether or not you like Autoconf, however, you have to agree that libtool has serious problems.

faragon 12y ago
"Build systems", like the GNU one (autoconf/automake/libtool/etc), cmake, or others, theoretically "solve" the need of your project build in a newer/different platforms. However, in practice, in a newer OS "version" or newer platform, you have to "fix" things, again. In my opinion, when possible, it is better to stuck to standards, and use just a Makefile for POSIX targets (it allows context detection) and a custom scripts or Makefiles for exotic platforms. In the end, the reason for e.g. Autoconf, is the mess of different non-standard crazy stuff. Why not to agree a build standard base, at least for the C language and library handling?
- mcguire 12y ago
  It's a nice, principled idea, but what happens when someone says, "We'll give you lunch money if you'll make your software work on ..."?
justincormack 12y ago
Also many of these bugs are somewhat transient, and it is better to not support a buggy platform, or insist on manual patching until it is fixed, rather than build complex tests and workarounds in.
mcguire 12y ago
"How much easier does autoconf make things, really?" Speaking as someone who was a system administrator responsible for compiling a large number of packages across a wide variety of platforms (let's see, SunOS, Solaris, AIX, Irix, Linux, and HP-UX, all at different versions at different times) through the '90s and early 2000s, autoconf made things much, much easier. It doesn't help the developers any; each individual difference has to be identified by the developer. (My biggest complaint isn't that it's written in m4, but that there's no comprehensive list of what I need to do with it. That information makes up the m4 tests, but there was no documentation.) Don't like libtool? http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html

faragon 12y ago

"Build systems", like the GNU one (autoconf/automake/libtool/etc), cmake, or others, theoretically "solve" the need of your project build in a newer/different platforms. However, in practice, in a newer OS "version" or newer platform, you have to "fix" things, again. In my opinion, when possible, it is better to stuck to standards, and use just a Makefile for POSIX targets (it allows context detection) and a custom scripts or Makefiles for exotic platforms. In the end, the reason for e.g. Autoconf, is the mess of different non-standard crazy stuff. Why not to agree a build standard base, at least for the C language and library handling?

mcguire 12y ago
It's a nice, principled idea, but what happens when someone says, "We'll give you lunch money if you'll make your software work on ..."?

justincormack 12y ago

Also many of these bugs are somewhat transient, and it is better to not support a buggy platform, or insist on manual patching until it is fixed, rather than build complex tests and workarounds in.

mcguire 12y ago

"How much easier does autoconf make things, really?" Speaking as someone who was a system administrator responsible for compiling a large number of packages across a wide variety of platforms (let's see, SunOS, Solaris, AIX, Irix, Linux, and HP-UX, all at different versions at different times) through the '90s and early 2000s, autoconf made things much, much easier. It doesn't help the developers any; each individual difference has to be identified by the developer. (My biggest complaint isn't that it's written in m4, but that there's no comprehensive list of what I need to do with it. That information makes up the m4 tests, but there was no documentation.) Don't like libtool? http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html