4 ms·

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

by kanox 6y ago

> 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 lowest common denominator and this is both useless (nobody cares about 90s unix, everybody can install bash) and insufficient (bourne shell is not native on windows). Perhaps energy would be better spend on migrating everybody towards newer build systems or just plain makefiles. A lot of projects have migrated already, does anyone have statistics about what percentage of a distro like Debian needs autotools?

drewg123 6y ago
While we're here, can we please also get rid of libtool?
- nullnix 6y ago
  Folding that into Automake is under, well, fairly active or at least repeated discussion. :)
friend-monoid 6y ago
Also everyone uses package managers these days, and if you ever need to install a package manager manually, spending 2 seconds to specify the location of a certain library, or googling “cannot find -lpng”, doesn’t take much effort. The automatics of library finding is super complex and can really get in the way of package/repo maintainers. Today, it’s probably a better idea to optimise build systems to be used by people who understand how the relevant programming language finds libraries, and not to “help end users understand how to compile their code”. Autoconf often does a good job in having some “—with-libX11=some-path” but sometimes people just do weird stuff with their packages. But maybe I’m just butthurt from trying to package stuff to nixos and having too many “smart build tools” fail.
rleigh 6y ago
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's a massive misplaced priority in catering for 90s Unix platforms which have marginal use by hobbyists and zero commercial use, above current open source and proprietary platforms. 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. Likewise build systems. It's make-only. And what about language and platform feature tests and support for stuff like threading, locking etc. It's non existent other than some third-party support which is quite limited. It's for all these reasons, as well as other well documented problems, that I moved all my personal projects over to CMake, as well as work projects, and other open source projects. I needed to support Windows. I needed to support building libraries on multiple platforms. I needed threading support. I needed C++14, and C++17 support. For some open source projects I maintain both Autotools and CMake support. I've had several instances of people trying to build on e.g. Solaris and having problems. I always ask "Were you using the Autotools build, or CMake?" They tell me they used the Autotools and I suggest retrying with CMake. It always works. In short: portability to other Unix systems is inferior today compared with CMake. That's supposed to be its main advantage... Agreed about the shell. There is no point to M4 and it could be removed compatibly by replacement with shell functions. This was true a decade ago. It was even true two decades ago. With regards to migration. The time, money and effort required to upgrade the Autotools would be better spent on converting the affected project(s) to use CMake or some other more modern build tool. The functionality gap is simply too big to overcome at this point, and the contributor base for CMake is large. The FSF have only themselves to blame for their contribution and development practices hindering forward progress, as well as a lack of concern for the real-world needs for software development. The turnaround time for submitting a CMake change is a few days to get it change reviewed and integrated, and a few weeks to be in a release. I've converted some large and complex projects to use CMake over the years, including Xerces-C, Xalan-C, libtiff and others. All in all, that time was well spent, and I'd rather have done this than waste time updating Autoconf/make/libtool. Regarding Debian. Current unstable Build-Depends is 1999 (CMake), 1544 (Autotools), 395 (Meson). So I think we're a good way past the tipping point now. Full disclosure: I've done the FSF copyright assignment for Autoconf and Automake and submitted some major features like C99 support. I'm also a CMake maintainer and I've submitted many different changes there. Primarily lots of Find module support including the Boost support, but also some lower-level bits and pieces as well. The community surrounding CMake is very active and also very friendly to submissions from new people. Kitware really deserve appreciation and thanks for their fostering and growing the community and committing resources to it including timely and friendly code review.
tinus_hn 6y ago
> 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.
Nemo_bis 6y ago
> Are there even any notable commercial projects that use autotools? Did you even read the article? The work is supported by Bloomberg for their internal use with Python, a clear commercial usage. https://lwn.net/Articles/835687/ https://lwn.net/Articles/835687/ Bloomberg has about 10 G$/y in revenue. https://en.wikipedia.org/wiki/Bloomberg_LP https://en.wikipedia.org/wiki/Bloomberg_LP

by kanox 6y ago

drewg123 6y ago

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

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

friend-monoid 6y ago

Also everyone uses package managers these days, and if you ever need to install a package manager manually, spending 2 seconds to specify the location of a certain library, or googling “cannot find -lpng”, doesn’t take much effort. The automatics of library finding is super complex and can really get in the way of package/repo maintainers. Today, it’s probably a better idea to optimise build systems to be used by people who understand how the relevant programming language finds libraries, and not to “help end users understand how to compile their code”. Autoconf often does a good job in having some “—with-libX11=some-path” but sometimes people just do weird stuff with their packages. But maybe I’m just butthurt from trying to package stuff to nixos and having too many “smart build tools” fail.

rleigh 6y ago

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's a massive misplaced priority in catering for 90s Unix platforms which have marginal use by hobbyists and zero commercial use, above current open source and proprietary platforms. 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. Likewise build systems. It's make-only. And what about language and platform feature tests and support for stuff like threading, locking etc. It's non existent other than some third-party support which is quite limited. It's for all these reasons, as well as other well documented problems, that I moved all my personal projects over to CMake, as well as work projects, and other open source projects. I needed to support Windows. I needed to support building libraries on multiple platforms. I needed threading support. I needed C++14, and C++17 support. For some open source projects I maintain both Autotools and CMake support. I've had several instances of people trying to build on e.g. Solaris and having problems. I always ask "Were you using the Autotools build, or CMake?" They tell me they used the Autotools and I suggest retrying with CMake. It always works. In short: portability to other Unix systems is inferior today compared with CMake. That's supposed to be its main advantage... Agreed about the shell. There is no point to M4 and it could be removed compatibly by replacement with shell functions. This was true a decade ago. It was even true two decades ago. With regards to migration. The time, money and effort required to upgrade the Autotools would be better spent on converting the affected project(s) to use CMake or some other more modern build tool. The functionality gap is simply too big to overcome at this point, and the contributor base for CMake is large. The FSF have only themselves to blame for their contribution and development practices hindering forward progress, as well as a lack of concern for the real-world needs for software development. The turnaround time for submitting a CMake change is a few days to get it change reviewed and integrated, and a few weeks to be in a release. I've converted some large and complex projects to use CMake over the years, including Xerces-C, Xalan-C, libtiff and others. All in all, that time was well spent, and I'd rather have done this than waste time updating Autoconf/make/libtool. Regarding Debian. Current unstable Build-Depends is 1999 (CMake), 1544 (Autotools), 395 (Meson). So I think we're a good way past the tipping point now. Full disclosure: I've done the FSF copyright assignment for Autoconf and Automake and submitted some major features like C99 support. I'm also a CMake maintainer and I've submitted many different changes there. Primarily lots of Find module support including the Boost support, but also some lower-level bits and pieces as well. The community surrounding CMake is very active and also very friendly to submissions from new people. Kitware really deserve appreciation and thanks for their fostering and growing the community and committing resources to it including timely and friendly code review.

tinus_hn 6y ago

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

Nemo_bis 6y ago

> Are there even any notable commercial projects that use autotools? Did you even read the article? The work is supported by Bloomberg for their internal use with Python, a clear commercial usage. https://lwn.net/Articles/835687/ https://lwn.net/Articles/835687/ Bloomberg has about 10 G$/y in revenue. https://en.wikipedia.org/wiki/Bloomberg_LP https://en.wikipedia.org/wiki/Bloomberg_LP