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

11–20 of 88 posts

Re: Autotools Mythbuster

#11

Post by riffraff »

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.

there _is_ a huge amount of smart folks who worked or works on build systems. Sadly, it seems everyone is 80% better than the others in something and 20% lacking in something else.

For example, the SCons wiki has some interesting comparisons.

https://bitbucket.org/scons/scons/wiki/SconsVsOtherBuildTool...

Re: Autotools Mythbuster

#12

Post by humanrebar »

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.

Doesn't CMake count as a successor?

Re: Autotools Mythbuster

#13

Post by rwmj »

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.

Of course there are many alternatives (of the alternatives, I can only really recommend cmake).

The problems broadly speaking are:

* Assumptions: autotools assumes that only a basic Bourne shell is available, and a basic make, and that make is a good way to build projects. All of those are questionable, and certainly if you get rid of the assumption that you're only allowed to use ancient tools, you could immediately make autotools better, if only by removing all the shell cruft. But then someone will complain because your project doesn't compile on SunOS 4 or whatever.

* Familiarity: When I'm packaging your project for Fedora, I will not be pleased if you've used some obscure or half-assed build system. If you're using autotools, I may dislike it, but at least I can fix things.

The second one is a difficult one, because until your build system gets popular, it will never be familiar, and us packagers will keep cursing you. Once it's popular, it'll probably be quite crufty because it has had to handle all the horrible corner cases that autotools can do now.

Re: Autotools Mythbuster

#14

Post by rwmj »

humanrebar wrote: post #12
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.

Doesn't CMake count as a successor?

I think more like "differently bad". However of all the build systems out there (and as a Fedora packager, I have had to deal with many), I'd prefer if you used either autotools or cmake, because those are the ones we're most familiar with and we can fix things.

Re: Autotools Mythbuster

#15

Post by nbaksalyar »

DasIch wrote: post #3

Learning about autotools is an amazing source of fremdscham. The whole compilation/packaging stuff is hard to get right but autotools looks like someone completely gave up on producing a good, decent or even bad solution and just tried whatever didn't completely and utterly fail at the task. That everyone else just kind of seemed to go with it... there are just no words to describe how embarrassing that looks.

IMO it doesn't matter if there are better alternatives, as that's mostly a concern for new projects. The thing is, there's a good chance that you'll have to use autoconf at least once in your dev life, sooner or later, because very large number of major opensource projects use it (with no clear intent to switch). So at least you've got to be prepared and know how autotools are working.

Re: Autotools Mythbuster

#16

Post by jordigh »

DasIch wrote: post #3

Learning about autotools is an amazing source of fremdscham. The whole compilation/packaging stuff is hard to get right but autotools looks like someone completely gave up on producing a good, decent or even bad solution and just tried whatever didn't completely and utterly fail at the task. That everyone else just kind of seemed to go with it... there are just no words to describe how embarrassing that looks.

  but autotools looks like someone completely gave up on 
  producing a good, decent or even bad solution and just 
  tried whatever didn't completely and utterly fail at the 
  task.
That is more or less what happened, by their own admission, "why does it look like gorilla spit?"

https://www.gnu.org/software/autoconf/manual/autoconf-2.65/a...

Although I disagree that they didn't produce a tolerably decent solution. It's a near hopeless task to account for the differences of dozens of operating systems, even if most of them are all Unix-like, yet autotools still tried and mostly succeeded. Nowadays some build tools don't even attempt to solve this problem and only target Windows, Mac OS X, and Ubuntu, and usually only the latest version of each.

Re: Autotools Mythbuster

#17

Post by falcolas »

rwmj wrote: post #13
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.

Of course there are many alternatives (of the alternatives, I can only really recommend cmake). The problems broadly speaking are: * Assumptions: autotools assumes that only a basic Bourne shell is available, and a basic make, and that make is a good way to build projects. All of those are questionable, and certainly if you get rid of the assumption that you're only allowed to use ancient tools, you could immediately…

Yeah, I know it's a damned hard problem, but that's why I posted it the way I did. This was mostly an attempt to head off the typical cargo-cult hate against autotools.

Re: Autotools Mythbuster

#18

Post by rwmj »

Aissen wrote: post #10
DasIch wrote: post #3

Learning about autotools is an amazing source of fremdscham. The whole compilation/packaging stuff is hard to get right but autotools looks like someone completely gave up on producing a good, decent or even bad solution and just tried whatever didn't completely and utterly fail at the task. That everyone else just kind of seemed to go with it... there are just no words to describe how embarrassing that looks.

The big problem is that no one did a better solution. All alternatives are missing one or more crucial features of the autotools (most prominent being portability). And that is sad as well.

Cross-compilation is another. When I was building packages for the Fedora MinGW (Windows cross compiler[1]) project, it was mostly trivial to get things working if the package used autotools or cmake, and an impossible nightmare for everything else.

[1] https://fedoraproject.org/wiki/Features/Windows_cross_compil...

Re: Autotools Mythbuster

#19

Post by jordigh »

mikepurvis wrote: post #6
davexunit wrote: post #4

Earlier quoted context omitted.

The Autotools are better than every other supposedly better solution. I do a lot of distro packaging work, and I can say, without a doubt, that the most problematic software to package are the ones that don't use the autotools.

I don't know Autotools, but I find the CMake workflow to be tolerable. Can someone who knows both provide a comparison?

The golden idea in autotools is test for features not for versions. Allow me to explain.

The problem autotools tries to solve is building your software on a wide array of operating systems and configurations. A very attractive alternative approach taken by most, including CMake[1], is to have a big giant database of systems and what each system can do at which version. Thus, if you want to use a library such as, say, Qt, CMake has a Qt module that looks for Qt libraries, checks their versions, and reports that back to you. These databases of system versions and what is available at each version are necessarily always outdated.

Autotools instead gives you tools to write tests. Do you need this library? Which functions do you need from this library? What should those functions do?

When you're running a ./configure script, that's what autotools is doing. It's checking to see what kind of C library you have, what kind of Unix tools are available, how do those Unix tools behave. It is not going to trust version strings or software names. Perhaps the OS reports that it's Debian but in fact it's some derivative of Debian that changed some things around. If you were relying on CMake's hypothetical database of Debian features, it would fail on this not-quite-Debian system.

Over time, these tests get shared around and become part of the core autotools libraries, which is the other problem: autotools is now checking for the absence of certain features that have not really been missing in any system since 1995.

---

[1] CMake can perform autoconf-like feature checks too, but this is not as common as relying on its databases of systems and features.

Re: Autotools Mythbuster

#20

Post by davexunit »

jordigh wrote: post #19
mikepurvis wrote: post #6

Earlier quoted context omitted.

I don't know Autotools, but I find the CMake workflow to be tolerable. Can someone who knows both provide a comparison?

The golden idea in autotools is test for features not for versions . Allow me to explain. The problem autotools tries to solve is building your software on a wide array of operating systems and configurations. A very attractive alternative approach taken by most, including CMake[1], is to have a big giant database of systems and what each system can do at which version. Thus, if you want to use a library such as, say…

That was a nice explanation of what is both good and bad about Autotools. I would love to see the GNU project take that "golden idea" and use a better language (GNU Guile ;) because M4 just sucks.
Post reply on HN