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

61–70 of 88 posts

Re: Autotools Mythbuster

#61

Post by icebraining »

kazinator wrote: post #57
scrollaway wrote: post #46

Earlier quoted context omitted.

> I've used autotools for decades because everything else is worse. I take it you've used CMake - could you explain in which ways you think it's worse than autotools? I agree it has concerning design flaws, but they don't come anywhere close to autotools' and I'd say CMake is overall dozens of times saner.

Does CMake generate a deliverable which builds on a machine that doesn't have CMake installed? With full incremental build support and all, so reasonable development can take place on that system?

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.

Re: Autotools Mythbuster

#62

Post by hp »

dankohn1 wrote: post #56

Could anyone speak to why you would use Autotools today in a new project rather than gyp [0] (created by the Chrome team because Autotools sucks) or waf [1]? How many people really have a requirement to support more than just Windows, OS X, and Linux? I can understand not wanting to rip out a working Autotools implementation of a legacy project, but it's greenfield use should decline to zero. [0] https://gyp.gsrc.io/…

Historically they have supported a lot of things the others didn't or didn't easily support: cross-compilation, changing the prefix/libdir/datadir, creating tarballs, "distcheck" to automatically check the tarball works, libtool, etc. Also lots of Linux tools are built around autotools, for example it's much much easier to rpm-ify or deb-ify an autotools tarball. Another example, there's gettext integration for autotools, automated tools for translators might rely on autotools, etc.

I'm probably listing the tip of the iceberg as far as network effects. In the Linux/Unix world, autotools is (or at least historically was) what everything and everybody knows how to deal with, and non-autotools is annoyingly nonstandard.

Your gyp link there says for example that its main goal is IDE support; a total non-goal for autotools. Unix/Linux C developers largely do not use IDEs. And the autotools goals probably aren't in gyp's list of priorities. So while they both "build the project" they have pretty different goals.

The autotools goals don't always make sense anymore. For example the historical idea that the shipped tarball would only depend on POSIX sh and not on any other binary made a lot more sense when people were hand-compiling stuff on their HP-UX than it does today where most binaries come from distributions.

If you're building a package mostly for Linux and maybe OS-X-as-Unix-compatible, especially one in C/C++ and open source, autotools probably still has a lot to recommend it.

Re: Autotools Mythbuster

#63

Post by kazinator »

icebraining wrote: post #61
kazinator wrote: post #57

Earlier quoted context omitted.

Does CMake generate a deliverable which builds on a machine that doesn't have CMake installed? With full incremental build support and all, so reasonable development can take place on that system?

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.

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

Re: Autotools Mythbuster

#64

Post by icebraining »

kazinator wrote: post #63
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.

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.

Re: Autotools Mythbuster

#65

Post by [deleted] »

manawy wrote: post #43
jordigh wrote: post #41

Earlier quoted context omitted.

> I'm not sure what you mean by databases of systems and features... I didn't really mean a literal database. I meant stuff like this: https://github.com/Kitware/CMake/blob/master/Modules/FindQt4... This is pretty typical CMake. It's encoding that for a particular version of Qt, add a few more compilation flags. It's a "knowledge base" of Qt versions encoded as a CMake module. The autoconf way would be to try to link…

I'd argue that for Qt this approach makes sense because they provide a well defined API that they stick too. The developer can also ask for specific component if it just want them (like QT GUI, QT SVG...). I agree that this is more problematic with less common, more buggy libs where the API keep changing, but in this case it's quite easy to check for specific files, specific functions, ... All this assumptions have h…

[deleted]

Re: Autotools Mythbuster

#66

Post by jerf »

nickpsecurity wrote: post #53
jerf wrote: post #51

Earlier quoted context omitted.

A solution can be no simpler than the essential complexity of the problem it is solving. It is not clear to me that the essential complexity of the problem is significantly simpler than the autotools solution. Across the totality of all C/C++-using systems, across all of the mostly-POSIX and vaguely-POSIX-ish systems, across all the libraries, the toolkits, the OSes, across the decades, across all of what it is tryin…

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…

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 perhaps needing it)?

The problem isn't even that the answers to those question are bad and preclude all changes... the problem is that there isn't even a concrete method for determining the answer! And you only need to have experience with trying to remove one or two features before the desire will be seared out of you by firebrands wielded by angry crowds.

I've tried to remove much simpler "obviously unused features" out of much smaller codebases in environments all under the control of one corporation and gotten burned pretty bad, to say nothing of autotool's scope.

Re: Autotools Mythbuster

#67

Post by jokoon »

I confess that I don't even know how to write a makefile, but reading the comments here, should I understand that cmake is better than autotools? Or should I learn autotools instead of cmake?

Since cmake is more adopted, isn't cmake better ?

Re: Autotools Mythbuster

#68

Post by nickpsecurity »

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 --…

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.

Re: Autotools Mythbuster

#69

Post by nickpsecurity »

jerf wrote: post #66
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…

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 fewer than 26 different names for the Fortran compiler my system does not have, and then spends another 26 tests to find out if each of these nonexistent Fortran compilers supports the -g option."

"so the input files for autoconf happen by copy and paste, often hiding behind increasingly bloated standard macros covering "standard tests" such as those mentioned earlier, which look for compatibility problems not seen in the past 20 years."

Looks pretty horrible to me. I think removing all that might piss off someone but they're refusal to upgrade shouldn't hold back everyone. Besides, why would I want all those tests running if most of them make no sense and it just adds overhead? And in an otherwise-unused language (M4)?

Looks like crap to me. They should get rid of it.

Re: Autotools Mythbuster

#70

Post by atso »

icebraining wrote: post #61
kazinator wrote: post #57

Earlier quoted context omitted.

Does CMake generate a deliverable which builds on a machine that doesn't have CMake installed? With full incremental build support and all, so reasonable development can take place on that system?

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.

Post reply on HN