3 ms·

> Have you ever tried to port a package that is using autotools to a platform that is not based on GNU/Linux? I think you mean Unix, not GNU/Linux. Porting fr

> Have you ever tried to port a package that is using autotools to a platform that is not based on GNU/Linux? I think you mean Unix, not GNU/Linux. Porting from one flavor of Unix to another is the raison d'etre of autoconf. It's really quite valuable when you're the one in charge of babysitting 20-year-old AIX or HPUX boxes. It's not even meaningful to talk about using the autotools on a non-Unix platform, since autoconf emits shell scripts. It sounds like you've run into problems with automake on a non-Unix platform generating Makefiles with shell code in it?

jff 14y ago
The thing is, 20 years ago maybe you developed on a Sun box, then the guy down the hall tried to compile it on his HP machine and it crapped itself because of some Sun-related assumption you made in setting things up. Then you mail it to a colleague across the state and he compiles it on OSF/1, hurrah! But now, people write Linux libraries, tested on a Linux box, for people running Linux, and only compiled on Linux. There may be OS X support. That's it. This is not the 1980s, where 10,000 Unixes bloomed. With 4 Makefiles, you could support Linux, OS X, Windows, and FreeBSD, and thus cover 99% of your audience. I'm sick of watching configure scripts take longer to run than the actual compilation.
- dlitz 14y ago
  The Linuxes still have different library locations, and things move around as new things get added (e.g. multiarch). Seriously, get over it and just use autotools.
  - jff 14y ago
    Get over it and just use your slide rule. Get over it and use punched card decks, timesharing is a fad. Get over it and use FORTRAN. Get over it and just use Windows.
- jimwise 14y ago
  Except that before "just supporting Linux (and maybe MacOS)" was the thing to do, it was "just support Sun (and maybe HP-UX)". And before that, it was "just support BSD/Vax (and maybe SVR2)". So, when you take a broader view than "just support what everyone uses", you're not just helping niche platforms -- you're future-proofing.

jff 14y ago

The thing is, 20 years ago maybe you developed on a Sun box, then the guy down the hall tried to compile it on his HP machine and it crapped itself because of some Sun-related assumption you made in setting things up. Then you mail it to a colleague across the state and he compiles it on OSF/1, hurrah! But now, people write Linux libraries, tested on a Linux box, for people running Linux, and only compiled on Linux. There may be OS X support. That's it. This is not the 1980s, where 10,000 Unixes bloomed. With 4 Makefiles, you could support Linux, OS X, Windows, and FreeBSD, and thus cover 99% of your audience. I'm sick of watching configure scripts take longer to run than the actual compilation.

dlitz 14y ago
The Linuxes still have different library locations, and things move around as new things get added (e.g. multiarch). Seriously, get over it and just use autotools.
- jff 14y ago
  Get over it and just use your slide rule. Get over it and use punched card decks, timesharing is a fad. Get over it and use FORTRAN. Get over it and just use Windows.
jimwise 14y ago
Except that before "just supporting Linux (and maybe MacOS)" was the thing to do, it was "just support Sun (and maybe HP-UX)". And before that, it was "just support BSD/Vax (and maybe SVR2)". So, when you take a broader view than "just support what everyone uses", you're not just helping niche platforms -- you're future-proofing.