One of the most common refrains that I hear lately, particularly when people discover Autotools Mythbuster is that we don’t need autotools anymore.
The argument goes as such: since Autotools were designed for portability on ancient systems that nobody really uses anymore, and that most of the modern operating systems have a common interface, whether that is POSIX or C99, the reasons to keep Autotools around are minimal.
This could be true… if your software does nothing that is ever platform specific. Which indeed is possible, but quite rare. Indeed, unpaper has a fairly limited amount of code in its configure.ac, as the lowest level code it has, it’s to read and write files. Indeed, I could have easily used anything else for the build system.
But on the other hand, if you’re doing anything more specific, which usually includes network I/O, you end up with a bit more of a script. Furthermore, if you don’t want to pull a systemd and decide that the latest Linux version is all you want to support, you end up having to figure out alternatives, or at least conditionals to what you can and cannot use. You may not want to do like VLC which supports anything between OS/2 and the latest Apple TV, but there is space between those extremes.
If you’re a library, this is even more important. Because while it might be that you’re not interested in any peculiar systems, it might very well be that one of your consumers is. Going back to the VLC example, I have spent quite a bit of time in the past weekends of this year helping the VLC project by fixing (or helping to fix) the build system of new libraries that are made a dependency of VLC for Android.
So while we have indeed overcome the difficulties of porting across many different UNIX flavours, we still have portability concerns. I would guess that it is true that we should reconsider what Autoconf tests for by default, and in particular there are some tests that are not completely compatible for modern systems (for instance the endianness tests were an obvious failure when MacIntel arrived, as then it would be building the code for both big endian (PPC) and little endian (Intel) — on the other hand, even these concerns are not important anymore, as universal binaries are already out of style.
So yes, I do think we still need portability, and I still think that not requiring a tool that depends on XML RPC libraries is a good side of autotools…
No, autotools is still very much needed even if no platform specific things are in use. –prefix and “make uninstall” are always needed IMHO.
Out of curiosity, doesn’t that show that much like CMake doesn’t play nice with non CMake-ish dependencies, Autotools don’t play nice with non Autotoo-lish dependencies? Hence requiring to “backport” Autotools builds to dependencies?What concrete help does Autotools bring when building, say, for Linux and Android. Which replacement functions were mandatory?Also, I would like to point that I found that adding Autotools to a proprietary library (supporting around 15 platforms, from micro-controllers, through phones, to desktop) imposes its own set of hoops: like having to #include <config.h> which is at the very core of Autotools.
There is nothing in Autotools that makes dependency any different to handle depending on their build system, particularly if they use `pkg-config` (which is agnostic to the build system, although the CMake implementation is known to be just terrible.)(GNU/)Linux – for once the Stallmanism is correct – and Android have slightly different interfaces and some functionality are missing, particularly around threading, although admittedly lots of the porting has more to do with Windows.As for `config.h`, you can avoid using it altogether if you don’t need it — you just need not to call `AC_CONFIG_HEADER`, but this is exactly why I argue that Autotools are still needed: bolting, or adding, Autotools to an old project the moment when you feel the need (because somebody needs to use it in another environment) is much more work than just adding the needed support to an already-present Autotools build system.
I’m not resisting Autotools, I’m using it happily. I have a GNU Makefile that autopilots its use for the others in team who are not familiar with it.A newcomer to our project just has to invoke e.g. make -C _autotools platform=qnx configuration=releaseThe GNU Makefile takes care of:1. invoking autoreconf with proper parameters2. creating the build dir (e.g. [project_root]/_autotools/build/[uname_s]-[uname_a]3. invoking …/configure4. cd to build dir5. invoke make (to run the Makefile generated by Automake)6. invoke make install (because our SDK expects shared libs to be end up in e.g. bin/lin-x64/*.so folder)This may look/sound bizarre but it brings me the following advantages:1. smooth transition from the previous build system2. those who don’t care about the Autotools “dance” just don’t have to3. I can easily add new GNU-like tool chains just by letting my GNU Makefile invoke configure with the proper tripletAll in all, I’m not criticizing Autotools. It’s find and I personally don’t like CMake. But for e.g. Android, at the very beginning they didn’t support building a proper toolchain so I took the same path as I did for Autotools: I let my GNU Makefile autopilot ndk-build, bringing the same advantages as mentioned above.To conclude, while it helps me every day, I feel like I’m not using it like I’m supposed to. I’m not including config.h nor do I rely on feature/function replacement.I hope sharing my profane use of Autotools helps 😉
Oops, of course cd to build dir happens before invoking ../[..]/configureAlso, I didn’t expect writing an underscore in uname_s and uname_a would switch the text to italic 🙂