I am a huge fan of Autotools and I have even created a macro collection for it (and yes, I still use it in 2021 and I recommend everyone to do the same – the elegance of libconfini’s build system would be impossible without Autotools) – plus, distro maintainers will love you if you use Autotools. A bit of problems though come with Anjuta, whose development has slowed down terribly after the creation of GNOME Builder.
I started learning Autotools thanks to Anjuta as well, but I would suggest that you begin editing your configure.ac and Makefile.am files manually as soon as possible. Autotools uses Turing complete languages (m4 and shell), and automated tools like Anjuta can come in handy for creating blank templates, but what comes next makes sense only if you do it by hand.
It is the only build system that does not ask users/maintainers to install dependencies, and offers plenty of packaging options (even renaming a package on the fly).
Maybe this discussion can better show the different opinions among developers/maintainers about GNU Autotools:
I don’t know what kind of reference you were expecting for a sentence like “distro maintainers will love you if you use Autotools”. The only thing you can do is to form your opinion on the basis of what you can read in online discussions, and possibly rely on the educated guess that the less dependencies the better for a package maintainer (zero, like in Autotools, is likely the ideal).
Personal taste plays a big role in what developers choose. However creating a package and installing a package are two different things. And while a developer who is new to the complexity of Autotools might hate it, the receiver of a plain configure script will not have much to complain, or any complexity at all to deal with.
And then there are developers like me, who just love the power that Autotools gives. Tired of calculating the next semantic version number by hand and dreaming of automatizing the versioning process simply by parsing the type of events that a release carries? Someone might have just created an m4 macro for that. And so on…
For developers it is ultimately taste. For distro maintainers though it is ultimately simplicity of use.
“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.
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).
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…
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.
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.
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.
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.
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.
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.
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:
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
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
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
Same as above for the binary version (libtool version info)
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:
A package needs backporting
For very strange reasons such backporting requires you to edit the configure.ac file
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?
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.
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.
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…
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.
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.
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.
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).