Autotools recommendations

Platform
15

This is a strange forum. A guy comes and ask information about Anjuta + Autotools and gets answered not to use Autotools. I try to give my help, since I actually like Autotools, but my answer gets split into another thread.

The original poster of course wonders why he/she should not use Autotools, but gets asked whether he/she is a troll.

In the meanwhile in this split discussion (which was born as one of the few actual answers to the original question), it looks like I have to pass an exam for liking Autotools, although I repeat that liking a build system is purely subjective.

@alicem

I am ready to switch to meson/CMake/whatever then. But you would need to explain to me how I can port the following features from Autotools to the alternative build system:

  1. Optionally forking (while building) the original code and create a split package of the library removing from both the public header and the code the functions that rely on I/O operations (for embedded systems) – currently configure --without-io-api does that
  2. Amending the library on the fly to make it possible to compile it for platforms that do not provide the C Standard library (freestanding environments) and guessing the missing data types accordingly (we must use compile checks only, or otherwise it won’t work when cross compiling) – currently configure --without-libc does that
  3. Exporting the version number everywhere so that I can write it only once every time I release a new version (by everywhere I mean source code, package.json, documentation, and so on) – currently configure --enable-extended-config does that
  4. Same as above for the binary version (libtool version info)
  5. Renaming the package during build – currently that is managed by Autotools transformations
  6. Make it work under Windows and update the current MSYS2 libconfini package accordingly
  7. Generate the .def and .exp files under Windows

I probably forgot to mention another similar amount of other features, but I don’t have a very good memory.

@hadess

If you touch only the Makefile.am files the configure script will not be re-generated, thus m4 will not be required. If you touch the configure.ac file instead the m4 code is run again. What concrete scenario of backporting asks you to touch the configure.ac file?

Just to make it clear, for Autotools to break in your scenario we need all the following conditions to be true:

  1. A package needs backporting
  2. For very strange reasons such backporting requires you to edit the configure.ac file
  3. The configure.ac file makes use of exotic macros

You must be a very unlucky distro maintainer. How many times in your lifetime did this odd event happen?