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

41–50 of 88 posts

Re: Autotools Mythbuster

#41

Post by jordigh »

manawy wrote: post #39
jordigh wrote: post #19

Earlier quoted context omitted.

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

> 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 a minimal program to Qt, and if it fails, try to see if adding more libraries makes the linking succeed.

Or this, for example:

https://github.com/Kitware/CMake/blob/master/Modules/FindOpe...

It is trying to account for two popular compilers on Windows but not with Cygwin. It's the whole chain of "if Windows, if cygwin, if mingw, if msvc" what I called a "database" above.

Doesn't clang work on Windows these days? What will this knowledge base do now? Shouldn't clang work almost like mingw? But because it misses the "if mingw" branch, code that probably would have worked for clang will be skipped over.

Re: Autotools Mythbuster

#42

Post by david-given »

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 which take numbers as arguments!).

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.

http://cowlark.com/2013-10-19-insane-make

Re: Autotools Mythbuster

#43

Post by manawy »

jordigh wrote: post #41
manawy wrote: post #39

Earlier quoted context omitted.

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

> 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 huge consequences in terms of velocity and ease of use.

Re: Autotools Mythbuster

#44

Post by jessaustin »

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

That script is 2500 lines long, and appears to have been written by a wizard. If my only other option was producing something like that, I'd just bite the bullet and use autotools. (IDK, that may be your point?)

Re: Autotools Mythbuster

#45

Post by buserror »

davexunit wrote: post #4
raverbashing wrote: post #2

One of the first lines "...the language used to write the configure.ac is called M4sh, to make clear that it's based off both sh and the macro language M4. " Tip: don't use Autotools

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.

While I also spend my day compiling packages [0] -- well CROSS COMPILING packages, and the worst problem I have, bar none, is autocrap.

Not only is it a giant pile of poo to try to 'repair' when it invariably does something the wrong way (like trying to fish my host's headers), but when compiling a distro, it's also the single tool that takes the most io/cpu of the host; forget compiling C++ - when you add up the zillion's time autocrap tries to see if I have strtok() in my C headers (hint, I do, since 1991); and then doing it again, over and over and over and over, the /compile/ time becomes rather negligible in comparison to the /autocrap/ time (especially on a modern host with -j12).

The thing is, in MOST CASES you could do it all with a page of gmake. pkg-config and all that are excellent at removing the need for autocrap. gmake has made heaps and bounds at simplifying what used to be the nightmarish Makefiles.

[0]: I'm the author of https://github.com/buserror/minifs

Re: Autotools Mythbuster

#46

Post by scrollaway »

adekok wrote: post #36
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…

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

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

Re: Autotools Mythbuster

#47

Post by scrollaway »

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…

Fun story, I have a set of scripts that extract, decompile and process various sets of files, outputting them into a build directory. At first I wrote shell scripts to automatically do all this, then I figured this is the sort of thing Make was built for (right?). This is what I ended up with after days of work:

https://github.com/HearthSim/extract-scripts/blob/master/Mak...

Turns out, Make kind of just assumes you're building a C project and makes a lot of further assumptions which made writing this Makefile a living hell. In the end, I didn't even manage to do proper checks for built files.

Make seems like a really poorly execution of a good concept. I think a large part of why autotools suck also comes from that.

Re: Autotools Mythbuster

#49

Post by manawy »

jordigh wrote: post #41
manawy wrote: post #39

Earlier quoted context omitted.

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

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

For your second example, this does not test for the compiler but for the provider of the SSL library. Clang does not provided it, so it's not a problem.

But I get your point.

My counter-argument is that more flexibility is left to the developer to assume stuff. These assumptions make things easier in most cases. In corner cases, then you need to provide explicit values to the module so he can find what you need.

Re: Autotools Mythbuster

#50

Post by david-given »

scrollaway wrote: post #47
david-given wrote: post #42

Earlier quoted context omitted.

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…

Fun story, I have a set of scripts that extract, decompile and process various sets of files, outputting them into a build directory. At first I wrote shell scripts to automatically do all this, then I figured this is the sort of thing Make was built for (right?). This is what I ended up with after days of work: https://github.com/HearthSim/extract-scripts/blob/master/Mak... Turns out, Make kind of just assumes you'r…

One thing that make appears completely unable to do cleanly is to build things twice, with different flags. You know, like 'build a release version and a debug version'. I've ended up having to write self-writing makefiles to do that. It's not as nasty as it sounds (but still pretty nasty): https://github.com/davidgiven/wordgrinder/blob/master/Makefi...

Plus, 'set a flag for just this file' is another thing that's appallingly broken. GNU Make has an extension to do that --- but if you use it, it makes your builds non-deterministic. (Flags propagate down the build chain; builds are not in a defined order; each file is built once regardless of the flags for that file; so if a file is reachable via more than one rule with different flags settings, it's pure luck which setting wins...)

Post reply on HN