4 ms·

> ...without needing to install a bunch of dependencies just for the build system... Ahem autogen.sh: command not found Autotools should be put out to pa

> ...without needing to install a bunch of dependencies just for the build system... Ahem autogen.sh: command not found Autotools should be put out to pasture. They serve literally no useful purpose at all in 2021.

tannhaeuser 6y ago
You don't need autogen.sh for a release tarball - the whole point of autotools is to generate a configure script that in turn generates a Makefile from Makefile.am etc. for you. However, if you're pulling a random commit from git rather than ungzipping a proper release tarball where autogen and co haven't been run on a dev system for release, then that workflow of course can't work. Which is one of the points of the linked discussion - that folks clone from git rather than doing "proper" releases, with cloned repos increasingly bringing their dependencies with them. Another point being that modern "language ecosystems" a la Go and Rust have their own canonical package management and aren't really made for polyglot development and linking with locally installed libs. I don't quite get the autotools hate; from a user PoV, it's the one build system that has worked extremely well over the decades with just POSIXly tools installed locally (make, sh, cc). The same can't be said for cmake. Not a particular fan of libtool, but arguably the invasive thing it does is a consequence of link-loaders such as ld.so still not getting lib resolution quite right in spite of ld.so'd heavy-handedness (Mac OS's is saner IMO). Another reality is that Docker builds are used to shield against lib breakage. IMO, what could be done to simplify builds is not to bring a new grand-unifying builder a la cmake, but to find common ground among GNU and BSD make, make generic "make" more powerful such that Makefile macro expansion works in more places than it does now, and rely solely on Makefiles and POSIXly/LSBly C/C++ header/macro def discovery in your source files rather than relying on automake, config.h, and -DHAVE_XYZ. Then slowly deprecate autotools and restrict yourself to target the much more uniform landscape of Linux, BSDs, and Mac OS we have today.
- shp0ngle 6y ago
  Autotools are _mostly_ fine from user's perspective (run configure, make, done) and horrible from devs perspective.
  - rurban 6y ago
    Quite the opposite. Autotools are wonderful for devs. I would never start a new project with cmake or bazel or ninja. Either autotools for the quality projects, or makefile projects for header-only like projects. Cmake is faster, but extremely limited.
pferde 6y ago
They may be of no purpose to you, but there are thousands, if not millions of people to which autotools is still incredibly useful, even with all its weaknesses and flaws.
- otabdeveloper4 6y ago
  autotools were originally designed to abstract away the platform-specific UNIX differences, 40 years ago. Today UNIX and those platform-specificities don't exist anymore. Instead we have Linux, FreeBSD and MacOS. Unfortunately, autotools haven't kept up and don't actually do anything useful to help you write portable code across Linux and MacOS.

tannhaeuser 6y ago

You don't need autogen.sh for a release tarball - the whole point of autotools is to generate a configure script that in turn generates a Makefile from Makefile.am etc. for you. However, if you're pulling a random commit from git rather than ungzipping a proper release tarball where autogen and co haven't been run on a dev system for release, then that workflow of course can't work. Which is one of the points of the linked discussion - that folks clone from git rather than doing "proper" releases, with cloned repos increasingly bringing their dependencies with them. Another point being that modern "language ecosystems" a la Go and Rust have their own canonical package management and aren't really made for polyglot development and linking with locally installed libs. I don't quite get the autotools hate; from a user PoV, it's the one build system that has worked extremely well over the decades with just POSIXly tools installed locally (make, sh, cc). The same can't be said for cmake. Not a particular fan of libtool, but arguably the invasive thing it does is a consequence of link-loaders such as ld.so still not getting lib resolution quite right in spite of ld.so'd heavy-handedness (Mac OS's is saner IMO). Another reality is that Docker builds are used to shield against lib breakage. IMO, what could be done to simplify builds is not to bring a new grand-unifying builder a la cmake, but to find common ground among GNU and BSD make, make generic "make" more powerful such that Makefile macro expansion works in more places than it does now, and rely solely on Makefiles and POSIXly/LSBly C/C++ header/macro def discovery in your source files rather than relying on automake, config.h, and -DHAVE_XYZ. Then slowly deprecate autotools and restrict yourself to target the much more uniform landscape of Linux, BSDs, and Mac OS we have today.

shp0ngle 6y ago
Autotools are _mostly_ fine from user's perspective (run configure, make, done) and horrible from devs perspective.
- rurban 6y ago
  Quite the opposite. Autotools are wonderful for devs. I would never start a new project with cmake or bazel or ninja. Either autotools for the quality projects, or makefile projects for header-only like projects. Cmake is faster, but extremely limited.

pferde 6y ago

They may be of no purpose to you, but there are thousands, if not millions of people to which autotools is still incredibly useful, even with all its weaknesses and flaws.

otabdeveloper4 6y ago
autotools were originally designed to abstract away the platform-specific UNIX differences, 40 years ago. Today UNIX and those platform-specificities don't exist anymore. Instead we have Linux, FreeBSD and MacOS. Unfortunately, autotools haven't kept up and don't actually do anything useful to help you write portable code across Linux and MacOS.