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

31–40 of 57 posts

Re: Introduction to the Autotools (2012)

#31

Post by scrollaway »

dmm wrote: post #30
scrollaway wrote: post #27

Earlier quoted context omitted.

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 t…

I agree, the CMake language is needlessly different and ugly. But it's readable and usable which matters a lot more.

I heard there's movement inside the CMake community to move to lua as a language, which would be awesome.

Re: Introduction to the Autotools (2012)

#32

Post by scrollaway »

striking wrote: post #28
scrollaway wrote: post #27

Earlier quoted context omitted.

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?

It's a "bigger problem". New languages bring new build systems and there really isn't much you can do about that.

However, what could be standardized is package distribution. I shouldn't have to have 10 different package managers for 10 different languages, each of them with different ways of expressing essentially the same metadata, etc.

As a language developer, I shouldn't be expected to create my own version of a package manager, with download, local / remote search, versioning, vcs support, upgrades, hooks, and a million other things. Package managers are complex beasts.

It's a bit like if every javascript project was expected to create its own http server. Except it's not http, it's a weird custom protocol they invented just for the sake of it. Naaaaasty.

Re: Introduction to the Autotools (2012)

#33

Post by ploxiln »

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 --prefix or CXXFLAGS as arguments to cmake, and cmake --help doesn't show what variables it does honor. Through googling and cargo-culting I've come up with some more cryptic replacements - `-DCMAKE_INSTALL_PREFIX:PATH=$PREFIX`, `-DCMAKE_CXX_FLAGS="-lrt"`.

Now that I look at the `cmake --help` output again, I notice that in the middle of its long list of unhelpful output, there's mention of `--help-properties` and `--help-variables`, but the output is super long.

Finally, I've seen indications that cmake is a huge pain if you want to add some custom targets and rules that it doesn't generate automatically for common languages in common layouts: https://samthursfield.wordpress.com/2015/11/21/cmake-depende...

I'm not a huge fan of autotools either, I tend to just write Makefiles directly (and not make any attempt at portability to Windows). It's actually not hard to correctly handle parallel, cross-platform, and cross-compiling support, just for linux / os x / bsd. It's a lot easier than fixing a cmake or autotools project that apparently messed something up in their configuration ...

Re: Introduction to the Autotools (2012)

#34

Post by GFK_of_xmaspast »

jordigh wrote: post #29
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 :…

> Autotools solves the problem of being portable to every conceivable Unix, including many Unices people don't use anymore, and including Unixified Windows.

"Portable to ultrix and dg/ux" is not much of a selling point.

Re: Introduction to the Autotools (2012)

#35

Post by Someone »

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.

For a classic rant on (a), read "A Generation Lost in the Bazaar" (https://queue.acm.org/detail.cfm?id=2349257)

I don't think you can skip the whole mess, though. Firstly, systems will have bugs, and standards will have holes, so you will have to check for specific behavior (in the case of POSIX, there's the added question of "what POSIX?")

The way forward, I think, is to periodically change the definition of what one can expect a system to have, and, after that, adjust configure scripts to assume that level is present.

Problem with that is that maintaining configure scripts for software isn't fun, so those for less used software will rot, anyways.

Also, that does nothing about the problem that building X requires several different versions of language L, plus language M, plus obscure language N, each of which basically get used as batch language, but got used because their respective developers were most comfortable with it.

Fixing that requires someone to spend time standardizing the build system across thousands of packages. That won't happen because it isn't fun, and not _that_ annoying for _that_ many people. Also, having fixed it, the probability of getting all upstream packages to accept your choices is zero.

And even if one were to do all of that, the problem that building Firefox requires libtiff, while Firefox doesn't handle TIFF images likely would remain.

Fixing that would require someone to properly engineer both the dependencies and the boundaries across thousands of open source packages. That won't happen, either. Extremely annoying issues such as (almost) circular dependencies (e.g. product P embeds a scripting language S, which uses library L, whose build system requires S) will be corrected, but nobody will either have the will to properly refactor all packages, the endurance to keep doing it, or the power to enforce it.

Re: Introduction to the Autotools (2012)

#36

Post by striking »

scrollaway wrote: post #32
striking wrote: post #28

Earlier quoted context omitted.

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?

It's a "bigger problem". New languages bring new build systems and there really isn't much you can do about that. However, what could be standardized is package distribution. I shouldn't have to have 10 different package managers for 10 different languages, each of them with different ways of expressing essentially the same metadata, etc. As a language developer, I shouldn't be expected to create my own version of a…

Arch Linux's "pacman" is exactly what you're looking for in those regards (to some degree). The only problem is that using pacman repositories instead of the language builtin ones means you're going to have issues with global installation and so on and so forth.

But you raise some really good points. I have to ponder this further.

Re: Introduction to the Autotools (2012)

#37

Post by Frondo »

jordigh wrote: post #29
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 :…

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.

Re: Introduction to the Autotools (2012)

#39

Post by digi_owl »

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…

CMake do provide a UI of sorts for exploring the various options. You have to run cmake . once first to get the defaults generated, and then you can use ccmake . to get a UI.

I find its insistence on all caps everywhere to be a bit of a annoyance though. But it guess it inherits that from make.

Re: Introduction to the Autotools (2012)

#40

Post by scrollaway »

striking wrote: post #36
scrollaway wrote: post #32

Earlier quoted context omitted.

It's a "bigger problem". New languages bring new build systems and there really isn't much you can do about that. However, what could be standardized is package distribution. I shouldn't have to have 10 different package managers for 10 different languages, each of them with different ways of expressing essentially the same metadata, etc. As a language developer, I shouldn't be expected to create my own version of a…

Arch Linux's "pacman" is exactly what you're looking for in those regards (to some degree). The only problem is that using pacman repositories instead of the language builtin ones means you're going to have issues with global installation and so on and so forth. But you raise some really good points. I have to ponder this further.

Of course! pacman is one of the best package managers out there (and the best I've personally used). But its developers sadly don't share in the vision of using pacman outside Arch Linux. It's a wonder it works on msys2.

It's a point I tried to raise in the past but without much success. If you want to start a project to fix this, email me (especially if it's centered around pacman - I'm an arch TU).

Post reply on HN