Talk:GNU Autotools

Needs elaboration
This is a nice start but it would be nice if experts in the field could elaborate the subject of the GNU tools, software builds, GNU style compiling and such. Please do so and make it an enjoyable and informative read for non-experts. Thanks. ---

Messybuttsecks (talk) 13:54, 17 June 2009 (UTC) There's a lot to elaborate, but for starters I've uploaded an image that captures all the essential processes in graphical form, neatly (I hope) divided in "who does what" to make it easier to understand. Mere mortal Wikipedia users can't upload images though, so it would be nice if someone could change it from being inline and into an uploaded image that can be thumbnailed, clicked, etc.
 * Can you post your image somewhere on the web? Daniel.Cardenas (talk) 15:53, 17 June 2009 (UTC)


 * Any user can upload images: click on the "Upload file" link at the left. Note that you should only upload images that you created yourself, not copies or conversions or modifications of images taken from elsewhere. —Steven G. Johnson (talk) 18:38, 17 June 2009 (UTC)

On references and personal opinion
It should be obvious that an article which contains exactly two sourced statements is in need of additional citations. In addition, the "limitations" section is completely unsourced and prescriptive, so I have tagged that too. Basically, the problem here is that too many things are being treated as trivial and obvious and thus not referenced - whereas to inexpert readers, nothing can be taken for granted here. Chris Cunningham (not at work) - talk 11:20, 23 September 2008 (UTC)
 * What do you mean by prescriptive? Daniel.Cardenas (talk) 18:46, 23 September 2008 (UTC)


 * Yes, it smacks of personal opinion and bias. The "limitations of..." is bad.  The very word "limitations" suggests "relative to something", but no relative thing is mentioned.  So the very heading is shoddy and misleading.  Its opening item (about Bourne shell compatibility) is simply factual (and, if anything, reflects one of its strengths, not limitations).  The next item (about Windows) is simply factual.  The following one (for if a project does not provide the user with "./configure") merely reflects bad usage by a software developer (who ought to know better); it should not be used to criticise the toolset itself.  I'm going to rework all this in the next few minutes... Feline Hymnic (talk) 14:40, 25 August 2012 (UTC)

Flow diagram
I'm not sure why "ed" is listed as the input for Makefile.am. Is that an attempt at a joke?

Also, in practice configure.ac files are almost always handwritten; "autoscan" is pretty rarely used, and even when it is used it is only run once at the inception of the project; including it in the flow diagram is probably misleading.

Finally, note that the configure script typically outputs both the Makefile and a config.h header file.

—Steven G. Johnson (talk) 18:43, 17 June 2009 (UTC)

Misleading sentence
"This means that running the configure script is often slower than the rest of the build process combined"

This is misleading, as it is only true for extremely small projects. For almost all real projects using autotools, compiling will be much slower than running configure. —Preceding unsigned comment added by 67.212.9.220 (talk) 07:29, 21 June 2009 (UTC)


 * Well, in my experience it's actually quite true, even for mid-sized projects, esp. ones that use also automake, the autoconf scripts can definitely take a long time to run, and the actual build runs blazingly fast, esp when fully parallelized on modern hardware.  There are a lot more popular mid-sized projects than huge ones.  However, the article should cite secondary sources, esp. on matters like this one (downsides of using a piece of software)..  --Mysidia (talk) 07:46, 21 June 2009 (UTC)


 * Indeed, I think statements like that one are inappropriate unless sourced. I've removed it from the article. If someone can find a quantitative source, I'd strongly support putting it back in. --R27182818 (talk) 22:19, 7 September 2009 (UTC)


 * The configure process does take a lot of time in small projects. However, when it comes to some big projects, such as compiling the GCC or X11, the configure script is just a piece of cake (and we often use much more time just to check if the output of configure is expected). Though I admit that the separate configure scripts during compiling procedure also occupy a lot of time, even been paralleled by make -jN. --LunarShaddowღIvy (talk) 05:05, 4 September 2011 (UTC)

Missing link in diagram
The diagram does not show a link between configure.ac and automake, but Automake manual clearly states this dependency : ''Automake scans the package's configure.ac to determine certain information about the package. Some autoconf macros are required and some variables must be defined in configure.ac. Automake will also use information from configure.ac to further tailor its output. Automake also supplies some Autoconf macros to make the maintenance easier.''

Proposing renaming article to Autotools
Who calls it the GNU build system? Autotools is the name I've consistently seen for automake and co. — Preceding unsigned comment added by 69.209.70.6 (talk) 21:56, 8 July 2011 (UTC)


 * Agree. Feline Hymnic (talk) 22:18, 24 August 2012 (UTC)


 * I disagree. See my comment below, under   Autotools is just part of the GNU Build System.  If the article is confusing Autotools with the GNU Build System, it should be rewritted as needed.  If it was written mostly about Autotools instead of the GNU Build System, the content that is specific to Autotools should be segregated in its own section within the article, with additional sections describing other parts of the System.  A fair amount of information on this matter is available from the Autotools FAQ. — QuicksilverT @ 15:51, 12 March 2016 (UTC)

Autoscan: Vestigial evidence of GNU's development
Autoscan is limited in use though still practical from the perspective of a new user to Autotools. condor (talk) — Preceding undated comment added 14:45, 19 May 2014 (UTC)

Article moved
I moved the article from "GNU build system" to "GNU Build System", because it is a proper noun, like a person's name, and because that is how its originator, the Free Software Foundation, calls it. See, e.g., https://www.gnu.org/software/automake/faq/automake.html#GNU-Build-System. — QuicksilverT @ 15:51, 12 March 2016 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified 1 one external link on GNU Build System. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive http://web.archive.org/web/20081013213002/http://sources.redhat.com:80/autobook/autobook/autobook_258.html to http://sources.redhat.com/autobook/autobook/autobook_258.html

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).

Cheers.—cyberbot II  Talk to my owner :Online 14:01, 1 April 2016 (UTC)

Not just Linux
"...designed to assist in making source code packages portable to many Unix-like systems..." This is not quite correct, the GNU Build System a.k.a Autotools is also used to create application and other packages for other operating systems such as Windows, but the tools ar also used to create other less frequent usage such as literary writing for authors working on complex academic texts. But at minimum the text should note that the tool base is also used for Windows application development as well as for embedded RTOS-related development. SoftwareThing (talk) 18:08, 25 May 2018 (UTC)


 * Windows: The section "Usage" seems to mention Windows. RTOS: Do you have some reliable sources for uses and notability? Feline Hymnic (talk) 18:58, 21 September 2019 (UTC)
 * Humm... You are correct that the Autotools software is utilized for far more product generation than mere software, I have seen Autotools used for software version control and configuration management, though the use that I saw was the artifact of a company implementing it due to a single engineer who did so as a means to quickly implement something while believing his solution was temporary. :) Only to have Autotools used for configuration management at the company for some five years now. :) But you are absolutely correct, Autotools lends itself toward much more than mere code generation. SoftwareThing (talk) 16:14, 23 September 2019 (UTC)

Propose rename to "Autotools" or "GNU Autotools"
In all my discussions and involvement over 15+ years with this, the commonly used generic name for the combined set of automake+autoconf+libtool always seems to have been "Autotools"; I don't recall ever hearing "GNU Build System". This "Autotools" name is backed up by GNU themselves at |An Introduction to the Autotools and the URL itself includes this name.

Unless there are reasons against, I propose renaming in about a week (end of September 2019). Feline Hymnic (talk) 17:01, 21 September 2019 (UTC)