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

51–57 of 57 posts

Re: Introduction to the Autotools (2012)

#51

Post by JoshTriplett »

ziotom78 wrote: post #49
JoshTriplett wrote: post #42

Earlier quoted context omitted.

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?

See the compiled version linked from the waf homepage, which projects using waf include in their source tree. That compiled version consists of a small Python stub followed by bz2-compressed data and a signature.

Re: Introduction to the Autotools (2012)

#52

Post by antonyme »

cperciva wrote: post #7
antonyme wrote: post #3

This documentation and video is good if you want to use autotools. But in 2016, you should really be asking yourself if autotools is the right choice. It is rather baroque, and there are many other choices these days that provide similar functionality for less developer time and effort.

To elaborate on "baroque": autotools spends a lot of time and effort on detecting behaviours which (a) no new Unix system has exhibited for at least two decades, and (b) your code almost certainly isn't going to be able to handle anyway. Autotools was great once, but the world has moved on. Write code which is POSIX compliant and skip the whole mess.

Yes, indeed. There are so many anachronistic features that bog it down with baggage and complexity and slowness.

It is easier now than ever before to port code between the major platforms, and especially with frameworks such as Qt.

Re: Introduction to the Autotools (2012)

#53

Post by antonyme »

scrollaway wrote: post #27
dmm wrote: post #10

Earlier quoted context omitted.

As a user building packages I like autotools because of its uniformity. If I want to change the install root I use "--prefix". If I want to crosscompile I can set "--build" and "--host". If I need to set a compiler flag, autotools actually observes CFLAGS. A few years ago I was trying to install a python extension and I couldn't figure out how to set a cflag on the native code it was compiling. It ignored CC, CFLAGS,…

CMake is a million times better than autotools and respects prefix-setting, cross compiling etc in standard ways as well. Uniformity is not unique to autotools. CPython extension building, however, sucks. setup.py is a bit of an abomination... It's really every language decides to reinvent the wheel for their own language. By now we could've had standards, and standard software, for package distribution and installat…

CMake actually does platform probing (test compiling with code fragments to identify platform features and quirks) in a similar manner to autotools. But it is much easier to work with, and significantly better documented. I find the syntax shouty and verbose but it does the job, and has proven its mettle in many large, complex cross-platform projects.

As for CPython extensions, I can relate also. Though the cffi makes some of it redundant, and Boost::Python is brilliant for wrapping C++ projects.

Re: Introduction to the Autotools (2012)

#54

Post by rhodysurf »

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…

Managing seperate build files for each platform sucks, especially on big projects. Thats where CMake is useful to me. It simplifies a lot for our company, but to each his own.

Agree that CMakeLists.txt is a terrible build script name though haha

Re: Introduction to the Autotools (2012)

#55

Post by jibsen »

ploxiln wrote: post #33
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…

CMake seems more difficult for the person building the software. I'm familiar with autoconf's configure options like --prefix and variables like CXXFLAGS, and if not I can see a reasonably short listing and explanation of them with `./configure --help`, and that list often includes other --enable-foo like options the project defined. CMake, on the other hand, does not (at least for the projects I've run into?) honor…

You might like this script that wraps cmake in a configure-like interface [1].

Also, CMAKE_INSTALL_PREFIX vs. --prefix is just different magical incantations. The obvious is sometimes what you are most used to.

[1]: https://github.com/nemequ/configure-cmake

Re: Introduction to the Autotools (2012)

#56

Post by antonyme »

highwind wrote: post #4
antonyme wrote: post #3

This documentation and video is good if you want to use autotools. But in 2016, you should really be asking yourself if autotools is the right choice. It is rather baroque, and there are many other choices these days that provide similar functionality for less developer time and effort.

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

CMake, Scons, Ninja, Gyp

There are many more, but these are more viable alternatives to auto tools.

https://en.wikipedia.org/wiki/List_of_build_automation_softw...

Re: Introduction to the Autotools (2012)

#57

Post by therein »

Frondo wrote: post #37
jordigh wrote: post #29

Earlier quoted context omitted.

> Linux and Windows, the whole nine yards That's the thing, if (a specific distribution of) Linux and Windows are all you care about, then CMake does the job just fine. Autotools solves the problem of being portable to every conceivable Unix, including many Unices people don't use anymore, and including Unixified Windows. Also, autotools solves the problem in a very specific way, test for features, not for versions :…

That sounds like what I said--portability to every conceivable unix, including ones that people no longer use--that autotools is good for legacy support. I'm trying to see what benefit there it to start a project in 2016 and wrestle with autotools, just so that you also gain access to unixes no one uses.

Yeah, exactly. I don't think my C++11 code would be portable to ultirx and dg/ux anyway. :)
Post reply on HN