Autotools recommendations

Platform
#6

“A survey of 1000 distro maintainers found that…” i.e. some quantitative data to support your assertion

I wouldn’t call an obscure macro language (m4) and perl “zero”, or indeed the wide range of things (awk anyone?) it may decide to call out to. And that’s without the mess of macro packs and the fact “autotools” is many separate packages with surprising relationships.

Oh and then for fun make changes how it handles # thus breaking your build and you get to deal with the “which of the half a dozen interpreteres reading this file messed up” problem.

1 Like
#7

The generated tarball does not depend on m4 or Perl, but only on the shell.

That sounds like an extremely rare event. Autotools is extremely conservative in breaking support for older syntax.

But as I said, use whatever build system makes you happy. I will still love Autotools and be happy that it is still well maintained.

In my humble opinion the only ugly part of Autotools is Automake. Using Perl was the wrong design choice, and they should have sticked to m4 also for the Makefile templates (replacing text from inside using a macro language is more powerful and robust than replacing text from outside using regular expressions).

#8

Autotools is extremely conservative in breaking support for older syntax.

Dude, almost every major release of autoconf or automake breaks previously-working code. This is just a fact. Distros that autoreconf every tarball, like Debian, and very familiar with this. I don’t think there’s been an Automake release in a long while, but if you look at its release notes, you’ll see lists of all the compat changes. Even more so with the recent Autoconf releases…

1 Like
#9

Oooh, actually Automake has been doing minor releases without compat changes. It’s the bigger releases that inevitably break things that used to work.

#10

A major release of Autoconf is pretty rare (current version is 2.X). What I see often happening instead is developers ignoring deprecation messages for years and then complaining that the new Autoconf version finally broke their code.

Autoconf is far from perfect. In the long term I believe they will have to replace m4 with a new macro language (that doesn’t exist yet), mostly due to the ugly argument syntax of m4, which forces weird indentation. As of today m4 is one of the best macro languages (not many macro languages exist though), but there are a lot of possible ideas for creating a better macro language. And Automake needs a rewrite.

I believe under the hood someone is exploring a global rewrite using Scheme, as GNU Make already offers Scheme support, but I don’t know much about that.

And yet, even in this far-from-perfect state, Autotools is able to beat the other build systems (in my opinion). But it does not make sense that we start a flame war. I am actually happy that other build systems exist and people can choose. A build system is ultimately a subjective choice.

#11

For me it’s convenient in some situations to be able to have full control over the generated makefile. That’s what using a macro language really gets you. It’s just not an option for other build tools that want to support multiple makefile backends. (cmake, meson, etc) And it somewhat causes problems for automake too which complains at you if you use any GNU make features because they aren’t portable. That leads to annoyances like having to use stamp files which then make the makefiles long and confusing and hard to maintain.

I don’t know if I could recommend it for a general use unless somebody really needs one of the uncommon systems that autotools supports.

#12

@jfrancis

You do touch another important point. Saying that Autotools packages depend only on the shell (as I did earlier) is not entirely correct in fact. They depend on the shell plus the make Unix utility. Currently Autotools allows you to use any flavor of make (GNU, BSD, etc.), at the cost of reducing the freedom of who creates a package. This made sense back in the days when GNU/Linux was just a tiny fraction of all the Unix variants in the wild, but it does not make sense anymore. Today we have to deal almost only with two variants, GNU and BSD, and GNU Make is available everywhere (as it is often the case for BSD Make too). Since GNU Make offers extensibility via Scheme, it can be a good idea to consider dropping support of all kind of weird implementations of make and stick only to GNU Make and its Scheme extensibility. I believe this will not be problematic for BSD/OS X users and will truly allow to rewrite Automake beautifully.

#13

the elegance of libconfini ’s build system would be impossible without Autotools

I’m very happy libadwaita build system is not as elegant, and is instead readable and maintainable.

6 Likes
#14

Actually, distro maintainers will hate you because it forces them to track down every source of every macro used inside the configure.ac or Makefile.am files every time they touch one of those types of files in a backport.

Just use meson, it’s actually readable.

/a distro packager of 21 years

2 Likes
#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.

@alexm

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?

#16

No. My first sentence links to the autotools FAQ answering the original question EXACTLY.

YOU then came and blew this up into a semi-theological discussion about belief systems.

You know, like in scientiffic papers, lilnks to direct quotes, references to web pages from distributions. You claim, you have to deliver. it is not my job to read between the lines of some random opion site like hackernews.

1 Like
#17

Please everyone let’s turn down the heat, remember that we are all colleagues here…

I think that would be very interesting, e.g. for GuixSD. It could be a good way to modernize it.

CMake and Meson both support build options, variables and compile checks, and have good support for Windows, we can go through it if you decide you want to try something new and can pick one. It’s up to you though.

1 Like
#18

This has happened to me more than once. I don’t know exactly how many times. It’s been much less of a problem recently since most desktop packages no longer use Autotools. But for Autotools projects, patches touching configure.ac are pretty common, and that necessarily requires running autogen.sh/autoreconf. Because we don’t run autogen.sh/autoreconf for all packages in Fedora, it is very common that this results in packages that fail to build. It might be due to an API break in autoconf-archive, or more rarely autoconf itself. But usually it’s just caused by a m4 macro being altogether missing. It’s a pain to try to hunt down which package provides a particular macro. Inevitably it results in a confusing syntax-related error message: only if you remember to use AX_REQUIRE_DEFINED religiously will you get a reasonable error message that tells you that you are missing a macro (but not where to find it). God forbid you receive a “I can’t build your project” bug report from a user missing autoconf-archive and therefore AX_REQUIRE_DEFINED…

1 Like
#19

It got split into another thread because the answers were spiralling into the usual “tabs vs spaces” and “emacs vs vi” thread, and it literally took two replies to get there.

Splitting topics is the least disruptive option before closing them, or deleting replies.

Having said that, I’m all for closing this particular discussion.

1 Like
#20

@jensgeorg

The original poster might have missed it, which might explain why they did not answer with “Thanks for the FAQ”, but answered with “Why do I need to switch from Autotools?”.

What I did was answering to a person who asked about Autotools-related stuff as a person who actually likes Autotools and is even mildly enthusiastic about it. But I agree with @jfrancis that we should all cool down.

@jfrancis

It would require an incredible amount of work in my case, without certainty that it will be possible/worth. What I needed was to “have full control over the generated makefile”, as you said in this comment. Once I had that, I exploited the fact that Autotools relies on m4 macros and I released my solutions in a separate m4 macro collection, so that everyone could benefit. This kind of micro-extensibility is what I see missing in other build systems.

@mcatanzaro

There is an “original sin” in the Autoconf Archive. For unexplainable reasons the AX maintainers decided to add a configure.ac file to their repository, so developers thought “Oh! It’s a package!”, and started to depend on it instead of exploiting it (by copying and pasting the macros that they needed manually).

This is one of the reasons that made me create the Not Autotools project (see also this discussion).

@ebassi

It’s fine, I was not really protesting against the split, I only found the accumulation of split + various answers unusual.

#21

You can make external modules and macros in CMake such as the ones maintained by KDE. In Meson it’s preferred to contribute extra modules upstream.

But anyway this discussion is getting way off-topic for Anjuta and GNOME.

#22

I don’t think letting IDE edit the build system automatically is a good idea, In visual studio there is XML based build system that is not human editable and to edit build parameters you should go into several windows and tool options instead of writing single line and then after some releases they might change tool option location and because of that many learning resources turned to be unusable in few years (worst of all vs compiler doesn’t have CLI at all).

in my opinion IDE way is not good for building stable and software and It will adds layers of complexity and unnecessary abstractions because they always try generalize and I don’t see any IDE can solve this issue not Anjuta, builder, VS, netbeans, eclipse, or inteliji.

although autotools comes with his problems but dependency of perl is more stable than python and autotools is mature.

since you are good at autotools I can’t recommend anything new to you but for any beginners reading this thread I recommend the following resources:

https://www.lrde.epita.fr/~adl/autotools.html
https://autotools.io/

1 Like
#23

@joinlaw

Although I do agree in general with this sentence, I also think that we should not pull down good ideas when they come. Anjuta was an excellent idea, which carried a lot of potential improvements for both itself and Autotools, and it’s a pity that it lacks maintainers at the moment.

I have tried to replace it with GNOME Builder, but the only thing I get from installing GNOME Builder is that I am forced to install flatpak, although I hate not using pacman for installing packages (once you install flatpak on Arch a lot of duplicate packages will appear in GNOME Software, one copy coming from Arch the other coming from flathub), and in my opinion AUR is a much better way to deal with bleeding edge software. Besides that, total lack of support for Autotools, so useless for me. And since I am firm in not wanting flatpak installed on my machine, I have always to uninstall GNOME Builder after installing GNOME.

Nothing against GNOME’s way of building software, but it should be clear that Anjuta and GNOME Builder have different scopes. The first is a general purpose IDE written for GNOME that relies on GNU Autotools, the second is an IDE designed to build software that complies with GNOME’s current way of building software.

EDIT I wanted to test if things were still like that after my comment, so I just installed GNOME Builder on Arch again, and it did not force me to install flatpak this time, so I will have to take back my previous statement.

SECOND EDIT Autotools support has improved a lot since last time I tried GNOME Builder, so I take back most of my comment.

#24

Just to make sure people after you don’t get the false understanding what GNOME Builder can or cannot do: GNOME Builder is perfectly capable to build autotools projects. Here is an example from your project @madmurphy

grafik
grafik1927×1181 201 KB

All i had to do is to clone the repo, hitting build and switch to the build terminal to execute the tests. You are probably right in the sense that not all convenience functions are available. For example we can’t derive tests from autotools project. But working with an autotools project is perfectly possible.

GNOME Builder does not force to install anything flatpak related unless you open an flatpak project. It helps in that sense to setup everything for the user to build it automatically. I think you can cancel it, switch to the native build and ignore the flatpak manifest and go for it. Nothing is forced at all here.

1 Like
#25

You are right, I checked and I edited my comment accordingly. Arch does not force anymore to install flatpak along with GNOME Builder.

So I have nothing against Builder anymore :slightly_smiling_face:

Just to make it clear that I did not dream it, this was Arch GNOME Builder’s PKGBUILD from March 25th:

You can see that it depended on flatpak-builder, which in turn depends on flatpak.