Talk:Autoconf

Criticism of autoconf

Most of the chatter I've read about autoconf is about how crap it is. I know of several projects that don't use autoconf because their authors hate it. However, I haven't used it much so I don't feel qualified to write about it (also I don't really have an opinion myself). I think some criticism needs to be cited here, else it seems quite biased in favour. Hairy Dude (talk) 16:25, 19 June 2008 (UTC)

Autoconf really sucks. it uses m4, an scripting language used nearly nowhere else. it is slow, the configuring takes longer than the compiling usually. the configuration files are really hard to write (i tried but gave up). it suffers (i think) from the halting problem making it nearly impossible to make a frontend for it. it generates makefiles and a lot of other files, this are the files you actually use and are too complex to debug. most likely there are a lot of other problems. i didn't even use it, i just tried it and saw it was really patched together. it's the wrong solution for the wrong problem which should not have existed in the first place (this pretty much sums it up). it's only used a lot because it's used a lot. a criticism section is a good idea, but not by me since a am far too biased. 213.84.168.252 (talk) 20:49, 13 October 2008 (UTC)

I think the current section about criticism is quite good (most of the "failures" of autoconf are listed), but I think that most of the points should be expanded as they are only partially true. For example the sentence "Generated 'configure' uses only manual-driven command-line interface without any standardization.": while it's true that there is no standardization, there are a lot of common practice in place (much more than most of all the alternatives) and a lot of shared macros (so for a given feature the user interface is usually the same) with a common repository http://ac-archive.sourceforge.net/ .--Giuliopaci (talk) 16:29, 6 November 2010 (UTC)

The criticism is badly overstated, in my experience. The page makes autoconf look considerably more complicated than it is, because the diagram displays the full-blown autoconf+automake+autoheader+aclocal ecosystem (what, they missed out libtool – gasp?!). The page also rather goes to town on its ‘Criticism’ of autoconf: while none of the points it makes are actually false, their significance is hugely exaggerated. Autoconf works better in practice than you would expect from a description of it, and its ubiquity means that (a) everyone knows what to do when confronted with a configure script, and (b) running a configure script requires no extra software installed (unlike, say, cmake). NormanGray (talk) 23:21, 5 November 2015 (UTC)

How does it do it?

"The Autoconf approach to portability is to test for features, not for versions. For example, the native C compiler on SunOS 4 did not support ISO C. However, it is possible for the user or administrator to have installed an ISO C compliant compiler. A pure version-based approach would not detect the presence of the ISO C compiler, but a feature testing approach would be able to discover the ISO C compiler the user had installed."

And how does autoconf check arbitrary programs if they provide ISO C compiler functionality? --Abdull (talk) 23:36, 8 December 2009 (UTC)

Users can tune the behaviour of the configure script by specifying where to find the functionality. For the cited example "CC=my_supposed_iso_c ./configure" will do the job. There are also macros that can be used to detect compilers, by investigating if they are in their standard installation location. The checks are performed by compiling (and eventually running) small programs that depends on specific behaviours. If the compilation is succesfully, the compiler is supposed to have the desired behaviour.--Giuliopaci (talk) 20:00, 6 November 2010 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on Autoconf. 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 https://web.archive.org/web/20041013190022/http://www.openismus.com:80/documents/linux/automake/automake.shtml to http://www.openismus.com/documents/linux/automake/automake.shtml
• Added archive https://web.archive.org/web/20060413182543/http://www.openismus.com:80/documents/linux/using_libraries/using_libraries.shtml to http://www.openismus.com/documents/linux/using_libraries/using_libraries.shtml

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

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 05:26, 22 October 2016 (UTC)