Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Autotools Mythbuster

autotools.io

Post reply on HN
Print view View original

71–80 of 88 posts

Re: Autotools Mythbuster

#71

Post by caf »

kazinator wrote: post #59
nickpsecurity wrote: post #53

Earlier quoted context omitted.

Even as an autotools critic, I totally understand that argument about the steps that were necessary for dealing with those portability problems. Well, way back in the day when they existed to the degree they did. Today, there should be much less complexity as the systems are more alike than different. What complexity is there is mostly a relic from days gone by that never got cleaned up because nobody wants to invest…

As someone who maintains a hand-written configure script for a project that I build on just a handful of platforms, I have to disagree. There is plenty of cruft there to detect and take care of. For example, recently I discovered that -D_FILE_OFFSET_BITS=64 works on 32 bit Solaris 10 for large file support. However, fseeko and ftello are not declared. For that you need something special, namely -D_LARGEFILE_SOURCE --…

Right. I have a 250-line utility that is currently testing for FreeBSD, OpenBSD and Darwin in the Makefile (due to differences in which libraries need to be linked to get a function, and differences in the include and library paths), and tests for FreeBSD, OpenBSD, NetBSD and Darwin in the .c file (due to differences in which header file functions are declared).

If someone tells me it doesn't work on, say, Solaris, my next step will be to convert it to autoconf. The essential complexity is still there.

Re: Autotools Mythbuster

#72

Post by caf »

nickpsecurity wrote: post #68
kazinator wrote: post #59

Earlier quoted context omitted.

As someone who maintains a hand-written configure script for a project that I build on just a handful of platforms, I have to disagree. There is plenty of cruft there to detect and take care of. For example, recently I discovered that -D_FILE_OFFSET_BITS=64 works on 32 bit Solaris 10 for large file support. However, fseeko and ftello are not declared. For that you need something special, namely -D_LARGEFILE_SOURCE --…

Appreciate the insight. So, are you on the side of the tool testing for every feature that might exist going back decades or modules that apply to each platform or version like we handle most dependencies? I think autotools' approach is overkill in terms of complexity and efficiency.

I'm not the parent commenter, but experience has taught me that testing for features, not versions, is definitely the right way to go. The alternative ends up with you creating a hodge-podge database of which features are present in which operating systems / versions, which is inevitably out-of-date, incomplete and wrong.

Only test for the features you actually care about, though. And at this point, it's perfectly fine for a new project to assume some baselines like POSIX-1996 and even C99 (unless you're targeting Windows...).

Re: Autotools Mythbuster

#73

Post by isolate »

nickpsecurity wrote: post #69
jerf wrote: post #66

Earlier quoted context omitted.

To the extent that that is true in some abstract sense, it's difficult to manifest it in real actions. Pick a feature you think is unused. Suppose hypothetically you could wave a wand and remove it. What are the odds that A: at least one current user would be impacted B: at least one major platform and C: a majority of users will be impacted at some point (i.e., something in their Debian stack ended up using it and p…

When I'm talking about relic cruft, I'm talking about things like PHK described here: https://queue.acm.org/detail.cfm?id=2349257 A few highlights: " yet the 31,085 lines of configure for libtool still check if and exist, even though the Unixen, which lacked them, had neither sufficient memory to execute libtool nor disks big enough for its 16-MB source code." "This is probably also why libtool's configure probes no…

Basically, Autotools is really stable software that has a ton of bugfixes in it. You can't just throw that knowledge away. The overhead of unnecessary tests is negligible compared to compilation costs for anything but the most trivial project. And, I'm pretty sure if you ask the mailing list, there's a way to turn off unnecessary checks for a Fortran compiler, probably by specifying the languages to support with AC_LANG or something.

Yeah, it's clunky and obtuse, but it works to give you portability to just about every system, POSIX or not. And the free support is first class if you ever have a problem.

Re: Autotools Mythbuster

#74

Post by krylon »

kazinator wrote: post #30
falcolas wrote: post #7

While it's quite popular to bash autotools, how about instead working towards a successor? One that's as easy for the end user to use as autotools, but with less technical debit. It's a hard problem, as evidenced by the inherent complexity in autotools, but there are a lot of smart folks who could apply their effort towards that goal.

I recommend a hand-crafted configure script, which provides the same usage interface to package builders, without Autocrap: E.g.: http://www.kylheku.com/cgit/txr/tree/configure

Thanks!

Re: Autotools Mythbuster

#75

Post by kazinator »

nickpsecurity wrote: post #68
kazinator wrote: post #59

Earlier quoted context omitted.

As someone who maintains a hand-written configure script for a project that I build on just a handful of platforms, I have to disagree. There is plenty of cruft there to detect and take care of. For example, recently I discovered that -D_FILE_OFFSET_BITS=64 works on 32 bit Solaris 10 for large file support. However, fseeko and ftello are not declared. For that you need something special, namely -D_LARGEFILE_SOURCE --…

Appreciate the insight. So, are you on the side of the tool testing for every feature that might exist going back decades or modules that apply to each platform or version like we handle most dependencies? I think autotools' approach is overkill in terms of complexity and efficiency.

I'm on the side of testing for features in a realistic, reasonably modern context which takes into account a set of supported platforms.

There is no point in testing for things for decades-old systems if you don't have any users on such installations.

The Autotools approach isn't overkill; it's overshoot. To declare something overkill, it has to solve the problem fully. Most of the Autotools-build packages in a GNU/Linux distro will not work on ancient systems, so they don't actually kill that problem. Even if the configure script actually runs through (unlikely), it will fail to detect things that the programs need. There won't be any fallbacks and so things won't build. If things happen to build, they might not run properly.

Porting requires work. You don't develop on system Y and assume it works for users of system X because you're on Autoconf. To call system X supported, you get a system X box with a development environment and port X. That is why, subsequently, the configure script works on system X flawlessly and everything builds.

Re: Autotools Mythbuster

#76

Post by kazinator »

caf wrote: post #72
nickpsecurity wrote: post #68

Earlier quoted context omitted.

Appreciate the insight. So, are you on the side of the tool testing for every feature that might exist going back decades or modules that apply to each platform or version like we handle most dependencies? I think autotools' approach is overkill in terms of complexity and efficiency.

I'm not the parent commenter, but experience has taught me that testing for features, not versions, is definitely the right way to go. The alternative ends up with you creating a hodge-podge database of which features are present in which operating systems / versions, which is inevitably out-of-date, incomplete and wrong. Only test for the features you actually care about, though. And at this point, it's perfectly fi…

Testing for features is the right way to go. If you add support for a new platform, there is no guarantee that the tests will all magically work. But a lot of them, in fact will. That reduces the amount of remaining work.

You could have a canned set of files, one per platform, containing some canned settings of variables. (The Pine e-mail program was a good example of this; its Alpine successor uses Autoconf.)

If you are porting to a new system, you have to guess which of the existing canned configurations is the closest one that will work and use it as a template.

Since there is no logic to detect if any of the features related to the configuration variables is actually present and in what form, it's just guesswork. Okay, it doesn't build. Now which of the relevant variables in the canned config is related to that breakage?

Re: Autotools Mythbuster

#77

Post by krylon »

david-given wrote: post #42
MichaelMoser123 wrote: post #25

GNU make has macros too, but these were added much later than 1991; Interesting if make macros were available earlier, would people have used them instead of autotools ? Thank you for the link on autotools, i will try to apply it if i am ever forced to do something with autoconf/autotools.

Trying to do anything non-trivial in GNU make macros is the most bewilderingly awful programming experience it is possible to have. They are horribly broken in every respect, from little stuff like awful syntax (whitespace is insignificant except where it's significant!) and poor error checking (detecting undefined variables? Who cares?) to the really big stuff (can't do arithmetic, despite having core functions whic…

> A while back I wrote a compiler which targeted GNU Make and made it run Conway's Game of Life (complete with hand-tooled arbitrary precision maths library written in make). I learnt more about this stuff than is healthy to know. The compiler output is... special.

One part of me wants to buy you a drink.

The other part wants to scratch my eyes out with a rusty fork.

Since I have no rusty forks at hand, and we probably won't ever meet, I'm just going to enjoy this as new record in "because-I-can"-land.

Re: Autotools Mythbuster

#78

Post by jedisct1 »

icebraining wrote: post #64
kazinator wrote: post #63

Earlier quoted context omitted.

Can we give everyone exactly the same tarball of a project and just have it unpack and build on their platform?

I think so, if you pre-generate the build files for every platform and distribute them all in the tarball.

Haha

Re: Autotools Mythbuster

#79

Post by icebraining »

atso wrote: post #70
icebraining wrote: post #61

Earlier quoted context omitted.

Yes to the first question, it generates platform-specific build files (e.g. Makefiles for Unix/Linux), which don't need cmake itself to build the software. Regarding the second question, I believe so, but I'm not sure.

Of course once the makefile is generated, there is no need to use cmake (as long as the project is not modified), but you cannot share a makefile generated by cmake, not even redistribute it. You cannot even re/locate it on your hard drive. The difference is that autotools generates source distributions that do not need autotools to build, while a cmake project always requires cmake when building.

Oh, I wasn't aware it wasn't distributable, my bad.
Post reply on HN