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

Rejuvenating Autoconf

lwn.net

Post reply on HN
Print view View original

11–20 of 21 posts

Re: Rejuvenating Autoconf

#11

Post by jwilk »

rleigh wrote: post #9
kanox wrote: post #3

> if your customers need to be able to build a shared library on Solaris, AIX, HP-UX, IRIX, and all the BSDs Are there even any notable commercial projects that use autotools? Autoconf solves problems that existed in the 90s unix market which are just not very interesting or relevant today. For a few decades now "portable" has meant linux, windows and mac. A lot of effort is spent on generating shell scripts for the…

There are likely to be some, but they will be a minority. And just like open source projects, their number will be dwindling. In both arenas, I've encountered CMake more than anything else over the course of the last decade. You're absolutely correct that Autotools is no longer synonymous with portability. If it ever was. Not catering for Windows or iOS means it's missing out on the lion's share of the market. There'…

> Current unstable Build-Depends is 1999 (CMake), 1544 (Autotools), 395 (Meson)

These days pretty much everything build-depends indirectly on autotools, via debhelper → dh-autoreconf → autoconf.

These numbers are probably more meaningful:

  $ wget -q https://deb.debian.org/debian/dists/unstable/main/Contents-source.gz

  $ zgrep -E $'(^|/)configure[.](in|ac)\t' Contents-source.gz | cut -f 2 | tr ',' '\n' | sort -u | wc -l
  5562

  $ zgrep -E $'(^|/)CMakeLists[.]txt\t' Contents-source.gz | cut -f 2 | tr ',' '\n' | sort -u | wc -l
  2455

  $ zgrep -E $'(^|/)meson[.]build\t' Contents-source.gz | cut -f 2 | tr ',' '\n' | sort -u | wc -l
  466

Re: Rejuvenating Autoconf

#12

Post by bonzini »

rleigh wrote: post #9
kanox wrote: post #3

> if your customers need to be able to build a shared library on Solaris, AIX, HP-UX, IRIX, and all the BSDs Are there even any notable commercial projects that use autotools? Autoconf solves problems that existed in the 90s unix market which are just not very interesting or relevant today. For a few decades now "portable" has meant linux, windows and mac. A lot of effort is spent on generating shell scripts for the…

There are likely to be some, but they will be a minority. And just like open source projects, their number will be dwindling. In both arenas, I've encountered CMake more than anything else over the course of the last decade. You're absolutely correct that Autotools is no longer synonymous with portability. If it ever was. Not catering for Windows or iOS means it's missing out on the lion's share of the market. There'…

> There is no point to M4 and it could be removed compatibly by replacement with shell functions.

Autoconf has been using shell functions since 2008 (support added by me :)). M4 is used to properly handle dependencies between tests and to store information that is used later when generating files.

Re: Rejuvenating Autoconf

#13

Post by tinus_hn »

kanox wrote: post #3

> if your customers need to be able to build a shared library on Solaris, AIX, HP-UX, IRIX, and all the BSDs Are there even any notable commercial projects that use autotools? Autoconf solves problems that existed in the 90s unix market which are just not very interesting or relevant today. For a few decades now "portable" has meant linux, windows and mac. A lot of effort is spent on generating shell scripts for the…

> For a few decades now "portable" has meant linux, windows and mac.

That’s a great way to stifle any kind of innovation. Some newcomers may still appear that are worthwhile.

Re: Rejuvenating Autoconf

#14

Post by nullnix »

drewg123 wrote: post #4
kanox wrote: post #3

> if your customers need to be able to build a shared library on Solaris, AIX, HP-UX, IRIX, and all the BSDs Are there even any notable commercial projects that use autotools? Autoconf solves problems that existed in the 90s unix market which are just not very interesting or relevant today. For a few decades now "portable" has meant linux, windows and mac. A lot of effort is spent on generating shell scripts for the…

While we're here, can we please also get rid of libtool?

Folding that into Automake is under, well, fairly active or at least repeated discussion. :)

Re: Rejuvenating Autoconf

#15

Post by mathstuf »

nwellnhof wrote: post #10
rleigh wrote: post #9

Earlier quoted context omitted.

There are likely to be some, but they will be a minority. And just like open source projects, their number will be dwindling. In both arenas, I've encountered CMake more than anything else over the course of the last decade. You're absolutely correct that Autotools is no longer synonymous with portability. If it ever was. Not catering for Windows or iOS means it's missing out on the lion's share of the market. There'…

> In short: portability to other Unix systems is inferior today compared with CMake. CMake requires a C++11 compiler and quite a few C libraries like libuv, so you can't even compile it on platforms like HP-UX.

Brad has submitted generic POSIX support to libuv for fallback support (I forget which platforms exactly were in consideration at the time). We even have a tracking issue for HP-UX support which tracks the status:

https://gitlab.kitware.com/cmake/cmake/-/issues/17137

Part of it is HP saying they'd have a C++11 compiler and then not, some is modern GCC being a problem to compile as well.

C++11 and libuv have vastly improved the situation in CMake's codebase itself and letting HPE hold everyone else hostage for that would not have been worth it (and it takes a lot for us to drop platforms). IRIX was dropped because its owner killed it off and we're looking at dropping support for macOS 10.9 and older (in premade binaries; feel free to compile yourself) because we don't actually have tests running on those older releases.

https://gitlab.kitware.com/cmake/cmake/-/issues/20825

Full disclosure: CMake developer here.

Re: Rejuvenating Autoconf

#16

Post by jnxx »

rleigh wrote: post #9
kanox wrote: post #3

> if your customers need to be able to build a shared library on Solaris, AIX, HP-UX, IRIX, and all the BSDs Are there even any notable commercial projects that use autotools? Autoconf solves problems that existed in the 90s unix market which are just not very interesting or relevant today. For a few decades now "portable" has meant linux, windows and mac. A lot of effort is spent on generating shell scripts for the…

There are likely to be some, but they will be a minority. And just like open source projects, their number will be dwindling. In both arenas, I've encountered CMake more than anything else over the course of the last decade. You're absolutely correct that Autotools is no longer synonymous with portability. If it ever was. Not catering for Windows or iOS means it's missing out on the lion's share of the market. There'…

> Not catering for Windows or iOS means it's missing out on the lion's share of the market.

Do you mean the market for free software?

I guess the GNU/Linux developers are not that keen to work for free to support commercial, nonfree platforms.....

Re: Rejuvenating Autoconf

#17

Post by jnxx »

rleigh wrote: post #9
kanox wrote: post #3

> if your customers need to be able to build a shared library on Solaris, AIX, HP-UX, IRIX, and all the BSDs Are there even any notable commercial projects that use autotools? Autoconf solves problems that existed in the 90s unix market which are just not very interesting or relevant today. For a few decades now "portable" has meant linux, windows and mac. A lot of effort is spent on generating shell scripts for the…

There are likely to be some, but they will be a minority. And just like open source projects, their number will be dwindling. In both arenas, I've encountered CMake more than anything else over the course of the last decade. You're absolutely correct that Autotools is no longer synonymous with portability. If it ever was. Not catering for Windows or iOS means it's missing out on the lion's share of the market. There'…

> And this doesn't just extend to operating systems, it also extends to language support. C++17, C++20, Rust, Go, Swift, you name it. It's not kept up.

Guix does support, for example, Rust and other languages relevant for Linux pretty well, and in a much better defined way than CMake.

Re: Rejuvenating Autoconf

#18

Post by jnxx »

rleigh wrote: post #9
kanox wrote: post #3

> if your customers need to be able to build a shared library on Solaris, AIX, HP-UX, IRIX, and all the BSDs Are there even any notable commercial projects that use autotools? Autoconf solves problems that existed in the 90s unix market which are just not very interesting or relevant today. For a few decades now "portable" has meant linux, windows and mac. A lot of effort is spent on generating shell scripts for the…

There are likely to be some, but they will be a minority. And just like open source projects, their number will be dwindling. In both arenas, I've encountered CMake more than anything else over the course of the last decade. You're absolutely correct that Autotools is no longer synonymous with portability. If it ever was. Not catering for Windows or iOS means it's missing out on the lion's share of the market. There'…

> primarily lots of Find module support including the Boost support, but also some lower-level bits and pieces as well.

Last time I checked, the CMake docs say that adding find module support is responsibility of the user. Which is a main reason why pkgconf-based dependency resolution works much better with other build systems. If you compile package abc on, say, Ubuntu, and it needs package xyz you do not need to bother about how it is found. You just install xyz.

What I want to say, CMake makes things way more complex and solves problems which exist only on Windows. Otherwise, it does not add much, and is a burden. Why should developers on Linux carry that burden?

Re: Rejuvenating Autoconf

#19

Post by rleigh »

jnxx wrote: post #16
rleigh wrote: post #9

Earlier quoted context omitted.

There are likely to be some, but they will be a minority. And just like open source projects, their number will be dwindling. In both arenas, I've encountered CMake more than anything else over the course of the last decade. You're absolutely correct that Autotools is no longer synonymous with portability. If it ever was. Not catering for Windows or iOS means it's missing out on the lion's share of the market. There'…

> Not catering for Windows or iOS means it's missing out on the lion's share of the market. Do you mean the market for free software? I guess the GNU/Linux developers are not that keen to work for free to support commercial, nonfree platforms.....

Most of the GNU software catalogue has historically been supported on nonfree platforms. Nothing to do with Linux here, it's not part of the equation.

None of this consideration is really concerning free software or proprietary software specifically. It's simply looking at cross-platform capability. If you need to develop cross-platform software of either sort, it's not typical to be able to ignore Windows. It's ~90% of the market. Similar considerations for other markets like smartphones.

None of that is reflective of my personal preferences, simply stating the requirements which drive the build system considerations of many projects. The GNU Autotools are unsuitable for the vast majority of current systems in existence, and that means selecting it for its portability is nowadays often not a possibility because their choice to not support common platforms makes it untenable.

Re: Rejuvenating Autoconf

#20

Post by Nemo_bis »

rleigh wrote: post #19
jnxx wrote: post #16

Earlier quoted context omitted.

> Not catering for Windows or iOS means it's missing out on the lion's share of the market. Do you mean the market for free software? I guess the GNU/Linux developers are not that keen to work for free to support commercial, nonfree platforms.....

Most of the GNU software catalogue has historically been supported on nonfree platforms. Nothing to do with Linux here, it's not part of the equation. None of this consideration is really concerning free software or proprietary software specifically. It's simply looking at cross-platform capability. If you need to develop cross-platform software of either sort, it's not typical to be able to ignore Windows. It's ~90%…

This is like complaining that the supply chain of oat milk is incompatible with 90 % of the systems that produce (cow-based) butter. We don't necessarily care.
Post reply on HN