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

31–40 of 88 posts

Re: Autotools Mythbuster

#31

Post by rockdoe »

mwcampbell wrote: post #28
rwmj wrote: post #13

Earlier quoted context omitted.

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…

Do you have any opinion on GYP, as used by Node.js and (last time I checked) Chromium? It seems to be particularly good at producing a large binary made up of a complex graph of static libraries.

Some simple things like compiling a single file with specific options quickly get needlessly complex, IIRC.

Re: Autotools Mythbuster

#32

Post by rockdoe »

pcwalton wrote: post #24
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.

> The Autotools are better than every other supposedly better solution. ... as long as you don't care about Windows (or iOS, or Android, etc.)

Autotools works for Windows and Android NDK builds.

No idea about iOS.

Re: Autotools Mythbuster

#33

Post by mannykannot »

falcolas wrote: post #17
rwmj wrote: post #13

Earlier quoted context omitted.

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.

The hatred is not really cargo-cult-like - you can understand it and still not be happy with it. That said, thinking about what it would take to replace it helped me come to an admittedly somewhat grudging acceptance of it. The testing alone...

Re: Autotools Mythbuster

#35

Post by rectang »

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.

The Apache Lucy project has an internal tool called "Charmonizer" which doesn't assume Bourne shell.

Charmonizer needs a supported C compiler command line interface (POSIX cc, MSVC, maybe others in the future) which can run "system()" commands in a supported shell (sh, cmd.exe).

The testing logic is all implemented in C code. Instead of shipping a shell script, there's one big amalgamated C file, plus a tiny "configure" wrapper to present a familiar interface.

Charmonizer hast given Lucy Autoconf-style probing on all our target platforms without adding any prerequisites beyond what Lucy already needs itself. This has made installing Lucy much easier for a wide range of users.

Right now Charmonizer remains a private component supporting only Lucy but if there were to be interest it could be broken out as an independent project at Apache.

http://github.com/apache/lucy-charmonizer

Re: Autotools Mythbuster

#36

Post by adekok »

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…

Even worse, autotools doesn't have the concept of modularization.

Look at the nginx configure scripts. They're hand-written, and modularized. Check for "foo"? There's a shell script. Autotools does the same thing via special-purpose autogenerated shell code.

That's why the configure script is 1000's to 10's of 1000's of lines of shell script. It's all auto-generated crap.

And autotools doesn't have the concept of bootstrapping. Building a C program? Great! Test everything with shell scripts. It might be more efficient to have C programs doing work, but no... it has to be the lowest common denominator.

Because managing multiple pieces is too hard. Why? Because there's no modularization.

I've used autotools for decades because everything else is worse. But I have a long-term deep-seated loathing of it which is hard to put into words.

Re: Autotools Mythbuster

#37

Post by adekok »

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.

GNU Make macros can't really replace "configure".

They can replace "automake". I've never understood why anyone thought automake was useful / sane. Going back 20 years, a few carefully written GNU Make rules were (a) simple, (b) understandable, and (c) portable.

Automake was more work for me than just writing GNU Make rules.

Re: Autotools Mythbuster

#38

Post by coherentpony »

hendry wrote: post #34

Please please please do not use ./configure aka autohell. Study the Makefiles in http://git.suckless.org/ Straightforward & fast.

Autotools solves the problem of having to write a makefile for every platform and also provides all the expected targets without having to write them all yourself.

Re: Autotools Mythbuster

#39

Post by manawy »

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…

I'm not sure what you mean by databases of systems and features...

I use CMake everyday and for me it's not a database but a set of modules. Each of this module will look for a particular thing. Some modules are better written than other but they all allow you to bypass them. Of course on obscure systems it will fail. That's why they are called obscure. But on systems following more or less the good practice, there will be no problem at all. On the others, you need to pass the specific path, but it will be true with autoconf too... no magic here...

Also in the doc, it is stated that if you rely on a specific flag/option/function then you need to test for it, and CMake gives you the tool to do it. That's a good practice everyone should follow.

But I agree, it's not always done. Like Autoconf, I guess it really depends on how well the developer understand the tool, and how much time he is ready to spend on it.

There's no magic, it's a complicated problem, with only complicated solutions. CMake is more attractive to me, because it allows me to do simple stuff easily, but more complicated operations are also possible.

Re: Autotools Mythbuster

#40

Post by notacoward »

This looks like a really useful guide through autotool hell, which is a fantastic thing to have, but it's not clear what myths are being busted so the name seems like a bit of a misnomer. Perhaps "Autotools Life Preserver" or something would be more accurate.
Post reply on HN