Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introduction to the Autotools (2012)

dwheeler.com

Post reply on HN
Print view View original

41–50 of 57 posts

Re: Introduction to the Autotools (2012)

#41

Post by JoshTriplett »

Frondo wrote: post #24

I'd like to jump in and endorse CMake, too, after spending some frustrated nights some years ago trying to add autogoo to a project. It was so mindblowingly easy to get CMake to work--to detect/find paths for libraries, work on Linux and Windows, the whole nine yards--on a project I had, I had the basic cross-platform functionality up in a matter of hours on my very first attempt. And the makefiles it produces genera…

I've worked on projects using autotools, and worked on projects using CMake. While CMake does add Windows support without having to use MSYS or similar, I've found the syntax and language semantics of CMake incredibly painful to work with.

CMake feels very "stringly typed", worse so than shell. For instance, the definition of if conditions: 'True if the constant is 1, ON, YES, TRUE, Y, or a non-zero number. False if the constant is 0, OFF, NO, FALSE, N, IGNORE, NOTFOUND, the empty string, or ends in the suffix -NOTFOUND. Named boolean constants are case-insensitive. If the argument is not one of these constants, it is treated as a variable.'

CMake has variables, and something vaguely like dictionaries, but the syntax again seems very string-like, with a SET() function and the PROPERTY syntax.

And on the flip side, CMake retains many of the quoting and argument splitting problems from shell scripting, without the well-established solutions for those.

In general, CMake seems like an exercise in minimal syntax: "can we build a language with no operators or symbols?". The result feels wrong in the same way COBOL does.

If you can treat CMake as a completely declarative language, it more or less works. However, the moment you have to actually use it as a programming language, it becomes painful.

I'd rather have shell scripts than CMake, and that says a lot.

Re: Introduction to the Autotools (2012)

#42

Post by JoshTriplett »

thallian wrote: post #26
highwind wrote: post #4

Earlier quoted context omitted.

Could you provide some examples of other choices that you speak of? Thank you.

waf ( https://waf.io/ )

Please don't use waf. It does not provide a stable API from version to version, and encourages projects to embed a binary compiled version of waf. Unlike autotools, where you can ship configure.ac and Makefile.am and expect developers to run autoreconf after obtaining the project from version control, you can't easily do the same thing with waf due to the lack of versioning.

Re: Introduction to the Autotools (2012)

#43

Post by wootoomoo »

rhodysurf wrote: post #13
joepvd wrote: post #6

This is awesome. Have just been strugglingh to get started with this the past few evenings. Will take this as my guide. Thanks for posting! BTW, good place to start learning the relevant parts of GCC?

If youre just starting something and not maintaining something older you should really take a look into CMake

I'm pretty baffled that people recommend CMake so often. I looked into it, and found:

* The worst scripting language ever, seemingly made by someone without even basic theoretical knowledge of language parsing. It's even worse than shell scripting.

* The same I-don't-care copypasta culture most autotools users seem to follow, but the free documentation was even worse (or at least back when I tried it). There's a book which I didn't have access to, though.

* Less enduser/packager friendly, with worse help texts, documentation, and features (seems to have caught up somewhat). Plus, everybody already knows how configure scripts work.

* The portability to Windows in reality means lots of if(WIN32) branches.

* The results are often brittle. This is also true of autotools in practice, but at least there is some info out there about how to write autoconf macros correctly. Even the .cmake files that ship with CMake seemed to be thrown together carelessly the last time I looked.

* Also, CMakeLists.txt must be the worst filename for a script I've ever seen. I'm only half serious on that one. I know it doesn't matter, but it bothers me terribly. It's ugly and misleading and makes me question the author's sense of aesthetics and basic competence.

CMake is terrible. Autotools is also terrible, but at least it's got an excuse. Just learn your damn tools. The real problem with autoconf is that nobody wants to invest any time learning about their build system and instead just copy-pastes it around, creating a brittle mess. From the CMake projects I've seen, it doesn't really solve this problem at all, creating a similar mess. And now your users have to install CMake and figure out how it works, and it doesn't even print a useful --help text.

Re: Introduction to the Autotools (2012)

#44

Post by gvalkov »

JoshTriplett wrote: post #41
Frondo wrote: post #24

I'd like to jump in and endorse CMake, too, after spending some frustrated nights some years ago trying to add autogoo to a project. It was so mindblowingly easy to get CMake to work--to detect/find paths for libraries, work on Linux and Windows, the whole nine yards--on a project I had, I had the basic cross-platform functionality up in a matter of hours on my very first attempt. And the makefiles it produces genera…

I've worked on projects using autotools, and worked on projects using CMake. While CMake does add Windows support without having to use MSYS or similar, I've found the syntax and language semantics of CMake incredibly painful to work with. CMake feels very "stringly typed", worse so than shell. For instance, the definition of if conditions: 'True if the constant is 1, ON, YES, TRUE, Y, or a non-zero number. False if…

I really liked the COBOL comparison. It's a real pity that nothing came out of their effort to use Lua[1] for the build language.

[1]: https://cmake.org/pipermail/cmake/2007-November/017971.html

Re: Introduction to the Autotools (2012)

#45

Post by joepvd »

wootoomoo wrote: post #43
rhodysurf wrote: post #13

Earlier quoted context omitted.

If youre just starting something and not maintaining something older you should really take a look into CMake

I'm pretty baffled that people recommend CMake so often. I looked into it, and found: * The worst scripting language ever, seemingly made by someone without even basic theoretical knowledge of language parsing. It's even worse than shell scripting. * The same I-don't-care copypasta culture most autotools users seem to follow, but the free documentation was even worse (or at least back when I tried it). There's a book…

Appreciate your opinion. Have been looking into CMake this evening, and my little impression was that it does not make the problem smaller, just different. The things I have been searching for, also did not yield that much high quality answers. Think I will stick to learn autotools enough, as that might come in more handy in general.

Re: Introduction to the Autotools (2012)

#46

Post by aurora72 »

joepvd wrote: post #18
rhodysurf wrote: post #13

Earlier quoted context omitted.

If youre just starting something and not maintaining something older you should really take a look into CMake

Thanks for your recommendation! Yes, I am just starting something small and new. And am now jumping the cliff of learning C, gcc, make, autotools, and gnulib-tool, of course all at the same time. Talking about a heap overflow ;) Is it correct that CMake is a replacement for GNU Make? So far, GNU Make has not posed a problem. Can CMake assume some roles of the other tools as well? I am looking to have this interesting…

CMake and GNU Make have only the word 'Make' in common, CMake is an automatic build tool while the GNU Make is just a GNU version of plain old make tool. CMake is there to prepare a proper Makefile for the "GNU Make" to consume.

Re: Introduction to the Autotools (2012)

#47

Post by aurora72 »

CMake is just another automatic build tool like the Autotools but without the Bourne shell requirement and the one which easily produces XCode / Visual Studio project files like the QMake. So as far as the CMake is concerned, it's not particularly useful nor more time saving than Autotools really.

Re: Introduction to the Autotools (2012)

#48

Post by adekok »

I've used autotools for >15 years now. My $0.02 is the following:

- autoconf is horrible but useful. It's bloated, slow, obtuse, and hard to use. But it encapsulates a portability layer which was useful 15 years ago... and less so today

- automake is horrible. A few simple rules in GNU Makefile syntax are good enough for the majority of projects. And it's easier to understand than automake

- libtool is horrible. It slows down every build by a factor of ~10. And you'd think that a program dedicated to building C programs would be written in C. You know, for speed. But no... it's written in shell. Horrible, horrible, shell. And it breaks the build. Pass "-L/foo -lbar"? It randomly converts it to an absolute path "/foo/bar.so". Pass in an absolute path so that you can link against the LOCAL build directory for testing? Screw you... it re-writes that to a relative path, and links against the system libraries.

- libltdl should be shot. I got rid of it in my projects 5 years ago, and never looked back. Everything sane has dlopen() these days.

If you want a nice cross-platform replacement for these tools, look at what nginx has done. ~8K lines of code, largely Makefiles split into ~50 lines. Simple, clean, and well organized.

Re: Introduction to the Autotools (2012)

#49

Post by ziotom78 »

JoshTriplett wrote: post #42
thallian wrote: post #26

Earlier quoted context omitted.

waf ( https://waf.io/ )

Please don't use waf. It does not provide a stable API from version to version, and encourages projects to embed a binary compiled version of waf. Unlike autotools, where you can ship configure.ac and Makefile.am and expect developers to run autoreconf after obtaining the project from version control, you can't easily do the same thing with waf due to the lack of versioning.

"Binary compiled"? Isn't waf a Python script?

Re: Introduction to the Autotools (2012)

#50

Post by ised »

Whenever this gets posted, comments seem to focus on what to use going forward. It seems obvious for most projects there are better alternatives.

However whenever I see autotools documentation I think of only one thing: it's worth learning how this old system works because, even if you will never yourself use it for your own projects, so much code written by others over past decades requires autoconf, automake, often libtool, and sometimes pkg-config.

For me, understanding how these old hacks work is very important in getting a large majority of open source software projects to compile after I make modifications, e.g., removing code.

Oftentimes I think that people who use autotools do not truly understand _how it works_, they have only figured out _how to use it_. This is reasonable but the problem is that autotools is very brittle, and if it breaks they have little idea how to fix it.

Post reply on HN