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

21–30 of 57 posts

Re: Introduction to the Autotools (2012)

#21

Post by dmm »

illumen wrote: post #16
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,…

Weird. CC and CFLAGS should both work with standard distutils.

That's the frustrating thing, other python libraries worked fine. That one must have been doing something weird.

Re: Introduction to the Autotools (2012)

#22

Post by rhodysurf »

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 does not take the place of GNU Make. It just generates your makefiles (or project files) for you. It handles all the hard parts, you just tell it what the files, libraries, and options you want are and it generates everything for you.

Here is an example project using CMake that is targeted for a MSP430 https://github.com/mpiannucci/HelloMSP430

Re: Introduction to the Autotools (2012)

#23

Post by shadowmint »

davexunit wrote: post #17
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.

All of the supposed replacements usually have a better interface but way worse functionality. Even just simple things like setting the installation prefix and finding shared libraries don't work as well or are left out. I do a lot of distro packaging work, and the GNU build system is by far the easiest to deal with. What the Autotools could benefit greatly from is a new UI. We can all agree that M4 sucks big time.

worse functionality how?

Im honestly curious why anyone still uses these tools.

Ive heard the 'alternatives do not work as well' argument before, but no one has ever managed to articulate to me exactly what it is that premake/cmake lack?

Is it literally just building debian packages in a moderately convenient manner?

Re: Introduction to the Autotools (2012)

#24

Post by Frondo »

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 generate pretty colored output. :-)

Autogoo knowledge seems like it's about on par with a deep knowledge of Xlib--good for anyone maintaining a legacy project, I'm sure.

Re: Introduction to the Autotools (2012)

#26

Post by thallian »

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.

waf (https://waf.io/)

Re: Introduction to the Autotools (2012)

#27

Post by scrollaway »

dmm wrote: post #10
cperciva wrote: post #7

Earlier quoted context omitted.

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.

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 installation instead of having pip, go get, npm and a thousand others.

Re: Introduction to the Autotools (2012)

#28

Post by striking »

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…

Is there a way other languages could fit into an established build framework like CMake?

Or is this a "bigger problem" that no one has really tackled yet?

Re: Introduction to the Autotools (2012)

#29

Post by jordigh »

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…

> 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:

https://news.ycombinator.com/item?id=10752054

Re: Introduction to the Autotools (2012)

#30

Post by dmm »

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 is very nice. I used it in my last big c++ project. The cmake language is ugly but I think it's a law or something that build tools use ugly languages.

One advantage of autotools is that it distributes everything as a portable shell script, so the user doesn't have to have a autoconf, etc installed. That was an advantage when giving tarballs to users to run on crazy cluster environments, for example. Anything that calls itself unix has to have a bourne shell. Oh well probably not that big of an advantage these days.

I was really complaining more about dunno-works-on-ubuntu GNUMakefiles and 90s scripting languages extention builds.

Post reply on HN