5 ms·

I approve of the concept, but I don't think this isn't the answer. For a start, it says if you want to install into non-standard directories, or enable/disable

I approve of the concept, but I don't think this isn't the answer. For a start, it says if you want to install into non-standard directories, or enable/disable options, you need to "edit your makefile". That isn't going to work for distributions, and I don't want to go to telling people to edit the makefile to change options on my program. Also, in my experience most autotools scripts do something, maybe dealing with inconsistent linker flags on mac vs linux, or enabling/disabling some debug option, or saying where to find some library (and optionally allowing building without said library). Coming up with some very simple format for configure scripts which are easy to read, and which do some simple search+replace substitution on a Makefile seems very sensible, and would get rid of awful autotools, is a great goal however.

francescovv 3y ago
> you need to "edit your makefile". That isn't going to work for distributions Is it not? [st] requires exactly that. And it works for distros, from what I can tell - debian/ubuntu, arch, almost everybody seem to ship it just fine. [st] https://st.suckless.org/ https://st.suckless.org/
- CJefferson 3y ago
  OK, maybe "not work well for distributions"? Looking at Debian, they are distributing a series of patches to the Makefile. Getting away from autotools by having every distro patch your makefile might still be better than autotools, but I'd hope we might be able to do even better?
  - francescovv 3y ago
    > Debian (...) are distributing a series of patches to the Makefile. Where do you see that, sorry? I'm looking at the "Download Source Package" section here: https://packages.debian.org/sid/stterm https://packages.debian.org/sid/stterm ...and the only patch on there is debian/patches/0001-fix-buffer-overflow-when-handling-long-composed-inpu.patch, which doesn't touch Makefie.
    - CJefferson 3y ago
      I wasn’t sure what the package was called, so I searched for ‘suckless’, and found this, with two Makefile patches. https://sources.debian.org/patches/suckless-tools/46-1/ https://sources.debian.org/patches/suckless-tools/46-1/
bonzini 3y ago
> Coming up with some very simple format for configure scripts which are easy to read, and which do some simple search+replace substitution on a Makefile seems very sensible, and would get rid of awful autotools, is a great goal however. That's CMake or Meson. Personally I prefer Meson because it gets rid of more cruft—at the cost of being more opinionated, but if it worked for projects as large as QEMU or PostgreSQL it probably will work for you. Also, even if you don't need to detect standard headers or features (and there are still differences between Linux, BSDs and Darwin even if they're smaller than they used to be) you will almost surely need pkg-config support, and that makes ESR's solution inadequate without manual work.
- bregma 3y ago
  The problem with pkg-config is that it's really really broken for cross builds. Meson depends on pkg-config so it's inappropriate for cross builds. It doesn't even pretend to support Canadian crosses. CMake works for cross builds, as long as the company has ported their proprietary CMake program to build for your target or you supply your own hand-rolled tools file and trick it into using that. Autotools works for cross building right out of the box almost every time.
  - bonzini 3y ago
    This does not match my experience, pkg-config can be used for cross compilation. In Autoconf terms it's a "tool", not a "program". If you're cross compiling to Arm from x86, you can either create a separate arm-linux-gnueabi-pkg-config installation that has a different search path for .pc files, or you can even just create a wrapper script that passes the right search path override to the system pkg-config. Either way, it's not a problem to cross compile with Meson, and most cross compilation environments are ready for it and have been for a decade or more. QEMU builds many cross compilation CI jobs and they handle Meson/pkg-config just fine. Where pkg-config goes almost irrimediably wrong, it's for multilib compilations (such as using -m32 to compile for 32-bit x86 on a 64-bit host). In that case there's no alternative to passing overrides in the environment. Which is pretty bad, not entirely broken I guess but pretty close. As to lack of support for Canadian crosses, that's a very niche case (and I say that as a former build system maintainer for GCC/binutils) and even then no build system is perfect. Looking again at QEMU, we need to build testcases for a dozen different targets, and Autoconf would only support one. In QEMU we use Meson for the more complex and configurable part of the build, and wrap it with a handwritten and decently readable configure/Makefile pair to handle target builds and orchestrate everything. We can do enough in Mason that the configure script's tasks are very specialized and would benefit very little from using a build-specific DSL like Autoconf's m4 dialect or CMake. For our use case it hits a sweet spot in terms of maintainability and is even more flexible than Autotools.

francescovv 3y ago

> you need to "edit your makefile". That isn't going to work for distributions Is it not? [st] requires exactly that. And it works for distros, from what I can tell - debian/ubuntu, arch, almost everybody seem to ship it just fine. [st] https://st.suckless.org/ https://st.suckless.org/

CJefferson 3y ago
OK, maybe "not work well for distributions"? Looking at Debian, they are distributing a series of patches to the Makefile. Getting away from autotools by having every distro patch your makefile might still be better than autotools, but I'd hope we might be able to do even better?
- francescovv 3y ago
  > Debian (...) are distributing a series of patches to the Makefile. Where do you see that, sorry? I'm looking at the "Download Source Package" section here: https://packages.debian.org/sid/stterm https://packages.debian.org/sid/stterm ...and the only patch on there is debian/patches/0001-fix-buffer-overflow-when-handling-long-composed-inpu.patch, which doesn't touch Makefie.
  - CJefferson 3y ago
    I wasn’t sure what the package was called, so I searched for ‘suckless’, and found this, with two Makefile patches. https://sources.debian.org/patches/suckless-tools/46-1/ https://sources.debian.org/patches/suckless-tools/46-1/

bonzini 3y ago

> Coming up with some very simple format for configure scripts which are easy to read, and which do some simple search+replace substitution on a Makefile seems very sensible, and would get rid of awful autotools, is a great goal however. That's CMake or Meson. Personally I prefer Meson because it gets rid of more cruft—at the cost of being more opinionated, but if it worked for projects as large as QEMU or PostgreSQL it probably will work for you. Also, even if you don't need to detect standard headers or features (and there are still differences between Linux, BSDs and Darwin even if they're smaller than they used to be) you will almost surely need pkg-config support, and that makes ESR's solution inadequate without manual work.

bregma 3y ago
The problem with pkg-config is that it's really really broken for cross builds. Meson depends on pkg-config so it's inappropriate for cross builds. It doesn't even pretend to support Canadian crosses. CMake works for cross builds, as long as the company has ported their proprietary CMake program to build for your target or you supply your own hand-rolled tools file and trick it into using that. Autotools works for cross building right out of the box almost every time.
- bonzini 3y ago
  This does not match my experience, pkg-config can be used for cross compilation. In Autoconf terms it's a "tool", not a "program". If you're cross compiling to Arm from x86, you can either create a separate arm-linux-gnueabi-pkg-config installation that has a different search path for .pc files, or you can even just create a wrapper script that passes the right search path override to the system pkg-config. Either way, it's not a problem to cross compile with Meson, and most cross compilation environments are ready for it and have been for a decade or more. QEMU builds many cross compilation CI jobs and they handle Meson/pkg-config just fine. Where pkg-config goes almost irrimediably wrong, it's for multilib compilations (such as using -m32 to compile for 32-bit x86 on a 64-bit host). In that case there's no alternative to passing overrides in the environment. Which is pretty bad, not entirely broken I guess but pretty close. As to lack of support for Canadian crosses, that's a very niche case (and I say that as a former build system maintainer for GCC/binutils) and even then no build system is perfect. Looking again at QEMU, we need to build testcases for a dozen different targets, and Autoconf would only support one. In QEMU we use Meson for the more complex and configurable part of the build, and wrap it with a handwritten and decently readable configure/Makefile pair to handle target builds and orchestrate everything. We can do enough in Mason that the configure script's tasks are very specialized and would benefit very little from using a build-specific DSL like Autoconf's m4 dialect or CMake. For our use case it hits a sweet spot in terms of maintainability and is even more flexible than Autotools.