5 ms·

But the point of libtool or autoconf is not to make it easier to build various programs on Ubuntu, it is to make it easier to build the same program not just on

by lutorm 12y ago

But the point of libtool or autoconf is not to make it easier to build various programs on Ubuntu, it is to make it easier to build the same program not just on Ubuntu and RedHat, but also on FreeBSD, OpenBSD, Darwin, Solaris, SunOS, Tru64, HP-UX, IRIX, AIX, and god knows what other systems. Even if Linux turned into a perfectly polished and neatly organized cathedral, you'd still need to get it to work on all those other systems. And most of those systems predate "the cathedral and the bazaar" anyway, don't they?

quesera 12y ago
libtool and autoconf are messy partial solutions to problems created by writing non-portable code. This is an aspect of the bazaar model, where reasonable standards (e.g. POSIX) are sometimes ignored in favor of novelty or minimal adequacy. The bazaar model embraces the mess, believing that something spectacular will emerge. The cathedral model argues that coherence produces better results. Both can point to successes. phk is arguing that the open source community has lost more than it has gained from accepting the bazaar as the one true way. Even in the last ten years, where has the innovation in operating systems come from? The CatB essay predates the book, and the idea predates UNIX.
- makomk 12y ago
  Any non-trivial code is non-portable between Unix systems in practice. No system implements all of POSIX, even when they do they often disagree on how parts of it should be implemented, and some software needs features that simply aren't in POSIX. (For example, high-performance webservers need a better way of polling for events than select/poll, and that's platform-specific.) As for libtool, anything that deals with shared libraries is inherently non-portable. The file extension they're created with and the compiler and linker flags to create them are entirely platform specific - POSIX won't help you there. (Also, a lot of libtool's hairyness exists because some older proprietary Unix systems don't support shared library dependencies.) If you're only planning on supporting open source OSes you don't actually need libtool though - their native toolchains are either the GNU one or something compatible with it, and include most of its functionality natively.
  - regularfry 12y ago
    And this is because there is nobody with authority to force the right solution. Compare POSIX to the Java spec: without Sun forcing coherence, "write once, run anywhere" would have died very early on, and we'd be saying the same thing about Java as you've just said about POSIX.
    - chris_wot 12y ago
      Curious though, what do you use: maven or ant?
      - regularfry 12y ago
        Neither.
  - quesera 12y ago
    > webservers need a better way of polling for events than select/poll, and that's platform-specific. POSIX was just an example, and it is possible to write portable code using #ifdef. But you have to have a goal of writing portable code. Re: libtool, most of the reason it's ever necessary is because of the historical rush and the incompatibilities created. Again, a single command line switch could handle that. Still, plenty of software which has clearly only ever been built for Linux requires libtool. It's just the way things are done, just like autoconf. It works, poorly, inefficiently, fragile-ly -- and to most, mysteriously. Appreciation for autoconf and libtool depends on one's position on the defeatism-pragmatism-idealism spectrum.
    - mcguire 12y ago
      "POSIX was just an example, and it is possible to write portable code using #ifdef.." Yes, two ways. One way uses autoconf (and tests each individual option to see which branch of the ifdef to use) and the other uses Imake (and has a big, continuously maintained database of which option to use on each system).
dietrichepp 12y ago
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.
- 12y ago
MBCook 12y ago
> Ubuntu and RedHat, but also on FreeBSD, OpenBSD, Darwin, Solaris, SunOS, Tru64, HP-UX, IRIX, AIX, So if you dropped SunOS, Tru64, HP-UX, IRIX, and AIX how many users would you use? How much of that configuration garbage would go away?
- lutorm 12y ago
  Yeah, that may be true today, but it certainly wasn't when these tools were conceived. (According to wikipedia, autoconf was first released in 1991.)
  - justincormack 12y ago
    But you don't have to go on using it...
- lstamour 12y ago
  Oracle's SunOS (now Solaris), HP-UX and IBM's AIX, plus the community-supported *BSDs and Darwin would be the only ones you'd see in the wild today, from that list. IRIX and Tru64 are retired or history, according to Wikipedia. ZDNet in April 2014 reports that Unix server share as a whole is 13.6% according to IDC, Oracle has 4.7% leaving 8.9% to competitors. Since many of these are RISC or Itanium servers, leaving them out means fewer compatibility headaches on multiple fronts. That all said, unless there's a testing service out there for this kind of enterprise hardware, I can't see how anyone writing open source code outside of large enterprises would be expected to support this configuration without patches from the community... which is probably why "standard checks" remain today. Nobody really knows if they're still needed or not, since the original patch might go back to the mid-90s.

by lutorm 12y ago

quesera 12y ago

libtool and autoconf are messy partial solutions to problems created by writing non-portable code. This is an aspect of the bazaar model, where reasonable standards (e.g. POSIX) are sometimes ignored in favor of novelty or minimal adequacy. The bazaar model embraces the mess, believing that something spectacular will emerge. The cathedral model argues that coherence produces better results. Both can point to successes. phk is arguing that the open source community has lost more than it has gained from accepting the bazaar as the one true way. Even in the last ten years, where has the innovation in operating systems come from? The CatB essay predates the book, and the idea predates UNIX.

makomk 12y ago
Any non-trivial code is non-portable between Unix systems in practice. No system implements all of POSIX, even when they do they often disagree on how parts of it should be implemented, and some software needs features that simply aren't in POSIX. (For example, high-performance webservers need a better way of polling for events than select/poll, and that's platform-specific.) As for libtool, anything that deals with shared libraries is inherently non-portable. The file extension they're created with and the compiler and linker flags to create them are entirely platform specific - POSIX won't help you there. (Also, a lot of libtool's hairyness exists because some older proprietary Unix systems don't support shared library dependencies.) If you're only planning on supporting open source OSes you don't actually need libtool though - their native toolchains are either the GNU one or something compatible with it, and include most of its functionality natively.
- regularfry 12y ago
  And this is because there is nobody with authority to force the right solution. Compare POSIX to the Java spec: without Sun forcing coherence, "write once, run anywhere" would have died very early on, and we'd be saying the same thing about Java as you've just said about POSIX.
  - chris_wot 12y ago
    Curious though, what do you use: maven or ant?
    - regularfry 12y ago
      Neither.
- quesera 12y ago
  > webservers need a better way of polling for events than select/poll, and that's platform-specific. POSIX was just an example, and it is possible to write portable code using #ifdef. But you have to have a goal of writing portable code. Re: libtool, most of the reason it's ever necessary is because of the historical rush and the incompatibilities created. Again, a single command line switch could handle that. Still, plenty of software which has clearly only ever been built for Linux requires libtool. It's just the way things are done, just like autoconf. It works, poorly, inefficiently, fragile-ly -- and to most, mysteriously. Appreciation for autoconf and libtool depends on one's position on the defeatism-pragmatism-idealism spectrum.
  - mcguire 12y ago
    "POSIX was just an example, and it is possible to write portable code using #ifdef.." Yes, two ways. One way uses autoconf (and tests each individual option to see which branch of the ifdef to use) and the other uses Imake (and has a big, continuously maintained database of which option to use on each system).

dietrichepp 12y ago

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.
12y ago

MBCook 12y ago

> Ubuntu and RedHat, but also on FreeBSD, OpenBSD, Darwin, Solaris, SunOS, Tru64, HP-UX, IRIX, AIX, So if you dropped SunOS, Tru64, HP-UX, IRIX, and AIX how many users would you use? How much of that configuration garbage would go away?

lutorm 12y ago
Yeah, that may be true today, but it certainly wasn't when these tools were conceived. (According to wikipedia, autoconf was first released in 1991.)
- justincormack 12y ago
  But you don't have to go on using it...
lstamour 12y ago
Oracle's SunOS (now Solaris), HP-UX and IBM's AIX, plus the community-supported *BSDs and Darwin would be the only ones you'd see in the wild today, from that list. IRIX and Tru64 are retired or history, according to Wikipedia. ZDNet in April 2014 reports that Unix server share as a whole is 13.6% according to IDC, Oracle has 4.7% leaving 8.9% to competitors. Since many of these are RISC or Itanium servers, leaving them out means fewer compatibility headaches on multiple fronts. That all said, unless there's a testing service out there for this kind of enterprise hardware, I can't see how anyone writing open source code outside of large enterprises would be expected to support this configuration without patches from the community... which is probably why "standard checks" remain today. Nobody really knows if they're still needed or not, since the original patch might go back to the mid-90s.