Do you understand how autotools works?

hydraMax · 03-09-2012, 01:32 PM

Just curious. Poll should be attached.

jhwilliams · 03-10-2012, 10:01 PM

Those three who "can hack all the config files and write [their] own macros" are either boisterously optimistic -- or should share their secrets! Autotools is scary.

GazL · 03-11-2012, 09:06 AM

I tried to read up on it once, but before I got to a point where I could actually use it I came to the conclusion that "the cure was worse than the disease". Makefiles may have their limitations, but at least they're understandable (for the most part).

hydraMax · 03-11-2012, 11:36 AM

Quote:

Originally Posted by GazL

I tried to read up on it once, but before I got to a point where I could actually use it I came to the conclusion that "the cure was worse than the disease". Makefiles may have their limitations, but at least they're understandable (for the most part).

In theory, at least, if you skip over using Automake, then you are basically just writing a normal Makefile (the Makefile.in), but with a bunch of free variables (directory locations, etc.) to work with given to you by the configure script. Or anyway that's the impression I got from documentation.

ntubski · 03-12-2012, 10:50 PM

Quote:

Originally Posted by jhwilliams

Those three who "can hack all the config files and write [their] own macros" are either boisterously optimistic -- or should share their secrets! Autotools is scary.

The "secrets" are all in the manual.

NevemTeve · 03-13-2012, 04:37 AM

They are way above the human understanding... (at least my understanding)

Random note: as a hobby, I compile open source software on AIX, it's quite common that I have to hack configure scripts (not that I actually understand them), for example:

Code:

find . -name configure -o -name config.rpath |\
while read FILE; do
    sed_repl 's|hardcode_direct=.*$|hardcode_direct=no|
              s|hardcode_libdir_flag_spec=.*$|hardcode_libdir_flag_spec=|' "$FILE"
done

KenJackson · 03-15-2012, 06:04 AM

There really needs to be a choice between 1 and 2. "haven't the foggest" does NOT describe me. I read through portions of the scripts to see what's going on. I've even improved my bash scripting skill be seeing the tricks they use. Though it's still very daunting.

Quote:

Originally Posted by NevemTeve

... as a hobby, I compile open source software on AIX, ...

AIX? Grief! Do you have a hulking IBM mainframe in your basement?

Markus Franke · 03-15-2012, 06:09 AM

I once stumbled on the following overview how all files are connected with each other and I found it really helpful.

http://www.adp-gmbh.ch/misc/tools/co...iles_used.html

ta0kira · 03-18-2012, 09:51 PM

Quote:

Originally Posted by KenJackson

There really needs to be a choice between 1 and 2. "haven't the foggest" does NOT describe me.

I agree. They are no worse than manually maintaining a large makefile.

I think a lot of people forget that the main purpose of autotools is to offload the work involved in allowing for a multitude of targets within the build system. The majority of what autotools does is customize makefiles to account for what's on the system you're compiling on. And, aside from what's inherently required for the build (e.g. compiler, linker, headers,) it really only needs a bourne shell and GNU make.
Kevin Barry

firstfire · 03-19-2012, 08:48 AM

Quote:

Originally Posted by ta0kira

I agree. They are no worse than manually maintaining a large makefile.

I think a lot of people forget that the main purpose of autotools is to offload the work involved in allowing for a multitude of targets within the build system. The majority of what autotools does is customize makefiles to account for what's on the system you're compiling on. And, aside from what's inherently required for the build (e.g. compiler, linker, headers,) it really only needs a bourne shell and GNU make.
Kevin Barry

..., `sed' and `awk'

orgcandman · 03-19-2012, 08:57 AM

and m4, and libtool.

The actual autotools API is pretty straight-forward, and writing an auto tools check macro in m4 is not terribly difficult.

The question is - do you really need such a hammer?

gnashley · 03-19-2012, 02:30 PM

the configure scripts do *not* need m4, libtool, perl, autoconf or automake. Only when *generating* autotools files are these needed.

orgcandman · 03-19-2012, 04:02 PM

Quote:

Originally Posted by gnashley

the configure scripts do *not* need m4, libtool, perl, autoconf or automake. Only when *generating* autotools files are these needed.

This is true, but I was talking about autotools, not just configure scripts. I was responding to tak0ira's comment about "The majority of what autotools does is customize makefiles to account for what's on the system you're compiling on. And, aside from what's inherently required for the build (e.g. compiler, linker, headers,) it really only needs a bourne shell and GNU make." Autotools is more than the configure script, and requires autom4te, libtool, sed/awk, autoconf, aclocal, automake, gnu-make, pkg-config to name (I think) the majority. Each of these has their own dependencies.

I've had configure scripts included with projects FAIL TO EXECUTE for a variety of reasons, requiring that I rerun autoreconf -i to regenerate a configure script. OR there's always the case where the project doesn't include a ./configure (gaim's CVS repository about 10 years back was this way). The advantage of autotools has less to do with the configure script itself as it has to do with the massive infrastructure used to generate that script. In those cases, you MUST have the full autotools environment or you can't even TRY to hack together a makefile that will work.

ta0kira · 03-19-2012, 04:15 PM

Quote:

Originally Posted by orgcandman

This is true, but I was talking about autotools, not just configure scripts. I was responding to tak0ira's comment about "The majority of what autotools does is customize makefiles to account for what's on the system you're compiling on. And, aside from what's inherently required for the build (e.g. compiler, linker, headers,) it really only needs a bourne shell and GNU make." Autotools is more than the configure script, and requires autom4te, libtool, sed/awk, autoconf, aclocal, automake, gnu-make, pkg-config to name (I think) the majority. Each of these has their own dependencies.

I've had configure scripts included with projects FAIL TO EXECUTE for a variety of reasons, requiring that I rerun autoreconf -i to regenerate a configure script. OR there's always the case where the project doesn't include a ./configure (gaim's CVS repository about 10 years back was this way). The advantage of autotools has less to do with the configure script itself as it has to do with the massive infrastructure used to generate that script. In those cases, you MUST have the full autotools environment or you can't even TRY to hack together a makefile that will work.

Certainly the developer needs those things, but if you make dist then the package will include configure, etc. and auto* won't need to be run again for it to work. If you're building from a repo and not from an archive intended for distribution, that's entirely different from what I was talking about in my previous post. And you've essentially just expressed a tautology: If the project uses autotools then you might need autotools installed to work on the project. You could say the same thing about flex/bison: If I write a parser and don't put the generated sources in the repo then of course you'll have to generate them, but that's not the fault of the tools.
Kevin Barry

theNbomr · 03-20-2012, 02:26 AM

I'd put it in the category of 'I really should learn this, now that I've seen what it does.' Kind of like emacs or Eclipse.
--- rod.