Autodafe 0.2 Released For Freeing Your Project From Autotools

[oleid]

A simple makefile in thoses cases will also tell you if it is installed by just failing to build it.

That would only work well if all the dependencies are available via e.g. pkgconfig.

[jabl]

That's what all arguments in favor of autocrap boil down to: let's suppose...

They have absolutely nothing to do with reality. In the real world the characteristics of most platforms are well known.

Even if try to build for something obscure like riscv32 with musl, of course the developers are going to build the platform in a way that is similar to the most popular platforms.

But in those cases you are unlikely going to build stuff manually, you are going to build the rootfs with tools like BuildRoot which deals with all the details.

So no, this hypothetical argument is only made by people who have never compiled for an obscure platform in their life.

Oh sweet summer child, if you think risc-v with musl is particularly obscure.

Since you think all this is hypothetical, for a real example in the not too distant past I was working on a project which supported, among others, HP-UX. For thread safety reasons we used functions from the POSIX Threads Extension (subsequently folded into the main POSIX spec) like localtime_r(). Now in their hurry to ship new features to customers HP-UX shipped a pre-standard draft of the POSIX threads extension, where unfortunately the function signatures are different than what was eventually standardized. How did we deal with that, do you think; I'll give you a hint, not by declaring such situations impossible.

I'm sure you think HP-UX is dead and irrelevant, and to an extent I agree with you, but it's not up to you to decide which targets some other project decides to support. Ok, anyway, lets continue to look at the wonderful world of the POSIX "_r()" functions. Turns out that GNU libc provides a non-standard version of strerror_r() (provided _GNU_SOURCE is defined which you most likely want to do for various other reasons), how are you going to support both that and the POSIX standard strerror_r()?

And it just goes on and on. Unless the software you're writing is trivial, or you restrict your support to just, say, whatever version of whatever Linux distro you yourself happen to use, you're going to have to deal with with the world as it is rather than as you wish it were.

Now autotools is messy and convoluted, and for a new clean sheet project you should definitely look into something like meson or cmake instead. But however much I wish it would not be the case, for software that targets multiple platforms, target-specific functionality and workarounds are the reality we live in and sticking your head in the sand isn't making all that go away.

Moreover, chances are whatever project you want to compile does not have a check for `foo` in their `configure` script, or the conditional code to workaround that, so autotools will fail anyway.

So because some projects don't have a check for `foo` , projects that do care about supporting targets with a non-standard `foo` shouldn't have the capability to do such checks? I don't understand the logic here.

[jabl]

It sounds like you don't think it's worth the maintenance cost to support BlubOS <= 8 here, so don't.

Huh? No, precisely because I want to support BlubOS <= 8 (and other systems with the non-standard `foo`) I use a build system that allows me to write a check for it and handle the situation. Autoconf (and similar tools) were written precisely because enumerating every platform and their quirks is a lot of error-prone work that needs to be continually be kept up to date.

Maybe their maintainers will package your software for it and carry downstream patches. The whole point of standards (like POSIX) is to build on a common foundation. It should not be your responsibility (as an application developer) to ship a clusterfuck of code that checks for POSIX bugs at build time.

A project of course has the right to tell the rest of the world to go pound sand if they don't have the same environment as the developer personally has, but, well, other projects exist that do try to target multiple platforms and thus do have to work around various platform-specific quirks. And not only quirks, of course. You might want to use some platform-specific functionality if available for various reasons.

[felipec]

Oh sweet summer child, if you think risc-v with musl is particularly obscure.

...

Now in their hurry to ship new features to customers HP-UX shipped a pre-standard draft of the POSIX threads extension, where unfortunately the function signatures are different than what was eventually standardized.

...

So because some projects don't have a check for `foo` , projects that do care about supporting targets with a non-standard `foo` shouldn't have the capability to do such checks? I don't understand the logic here.

I did not say it was particularly obscure, I said it was obscure, certainly more obscure than x86_64-linux-gnu.

And how many projects out there did use autotools to build a threaded program for your platform successfully?

Can you name even one?

If you really must have a check -- which is rare in the first place, you can implement the check yourself, you don't need autocrap for that. That's how FFmpeg and QEMU do it.

Are you going to claim FFmpeg doesn't have good platform support?

[lowflyer]

Just an observation: there are some really stinking C++ haters in this forum here.

[billyswong]

Since you think all this is hypothetical, for a real example in the not too distant past I was working on a project which supported, among others, HP-UX. For thread safety reasons we used functions from the POSIX Threads Extension (subsequently folded into the main POSIX spec) like localtime_r(). Now in their hurry to ship new features to customers HP-UX shipped a pre-standard draft of the POSIX threads extension, where unfortunately the function signatures are different than what was eventually standardized. How did we deal with that, do you think; I'll give you a hint, not by declaring such situations impossible.

I'm sure you think HP-UX is dead and irrelevant, and to an extent I agree with you, but it's not up to you to decide which targets some other project decides to support. Ok, anyway, lets continue to look at the wonderful world of the POSIX "_r()" functions. Turns out that GNU libc provides a non-standard version of strerror_r() (provided _GNU_SOURCE is defined which you most likely want to do for various other reasons), how are you going to support both that and the POSIX standard strerror_r()?

And it just goes on and on. Unless the software you're writing is trivial, or you restrict your support to just, say, whatever version of whatever Linux distro you yourself happen to use, you're going to have to deal with with the world as it is rather than as you wish it were.

Now autotools is messy and convoluted, and for a new clean sheet project you should definitely look into something like meson or cmake instead. But however much I wish it would not be the case, for software that targets multiple platforms, target-specific functionality and workarounds are the reality we live in and sticking your head in the sand isn't making all that go away.

All these quirks are OS-specific and compiler-specific, but not software project specific. I stand by what I wrote earlier, which is whatever wrapper scripts for this kind of problems should have been done once per platform and shared by all projects. A proper "build system" should allow custom instructions only for testing and bootstrapping new platform versions. Each software projects maintaining their own quirk workarounds is absurd.

[jabl]

I did not say it was particularly obscure, I said it was obscure, certainly more obscure than x86_64-linux-gnu.

Congratulations for engaging in pointless word-pedantery while completely missing the point. To make it even clearer: if you're looking for portability headaches, anything running Linux and either glibc or musl isn't much of a problem (well, things like ASM optimization can of course be a problem for rarer HW architectures, but I'm talking about software API issues here, locations of libraries and their headers etc., things that a build system usable for portable software must be able to figure out).

And how many projects out there did use autotools to build a threaded program for your platform successfully?

I'm unsure what you mean by "your platform" here?

Can you name even one?

I guess that depends on what "your platform" above refers to. If you mean HP-UX, then yes the particular software I mentioned did use autotools so I guess that's at least one I can name. And given how common autotools, for better or worse, is, I'm quite sure there's loads of other examples. But in general, no sunshine, I'm not going to go and do your homework; if you want to prove something you go out and dig up the supporting data yourself.

If you really must have a check -- which is rare in the first place, you can implement the check yourself, you don't need autocrap for that. That's how FFmpeg and QEMU do it.

Are you going to claim FFmpeg doesn't have good platform support?

I never said you must use autotools. I even specifically mentioned a couple of alternatives that I think are better. My argument is that given the reality of cross-platform development in languages like C and C++, a build tool that doesn't allow you to do various target checks at build time is crap and not worth spending your time on.

As for FFmpeg and QEMU, I'm not familiar with the development of either of these two projects, but just for kicks I went and took a look at QEMU git. And lo and behold, they use meson (good for them!), with a lot of various target checks. Just like what you'd use autoconf for if the project were using autotools. Which is exactly my point: A good build system for the reality of cross-platform development needs the ability to have build-time checks of the target.

[jabl]

All these quirks are OS-specific and compiler-specific, but not software project specific. I stand by what I wrote earlier, which is whatever wrapper scripts for this kind of problems should have been done once per platform and shared by all projects. A proper "build system" should allow custom instructions only for testing and bootstrapping new platform versions. Each software projects maintaining their own quirk workarounds is absurd.

Once again we're looking at the difference between the world as it is, and what someone thinks it should be. That a project like you envision doesn't exist might be a hint that the problem isn't as easy as you think it is.

(And of course, not all checks need to be fully custom for each project. Autotools (via autoconf-archive), and cmake ship with a large set of builtin tests for various things, and of course many libraries provide stuff like pkg-config or cmake snippets that downstream consumers can use.)

[hsci]

I can only recommend everyone using C and C++ to use Meson. It is also usable with Rust and Java.

* Readable and clean syntax. Scripting not required.
* Built-in dependency management: host libraries, self declared dependencies or wrap-db.
* Central, well maintained documentation.

I can read and understand makefiles but reading a configure.ac, configure.sh or config.status from Autotools horrible. Furthermore the end-user interface consisting of autotools is also a problem because it is not clear when to use autogen.sh, autoreconf -i (probably right) and afterwards ./configure and only finally make. Therefore porting all of them directly to a single makefile is probably a step forward?

Real world examples
Autotools: configure.ac and autogen.sh and more (again: As far as I know you better use autoreconf)
Meson: meson.build and src/meson.build (splitup between project setup and source is common common for large projects)

[felipec]

Congratulations for engaging in pointless word-pedantery while completely missing the point.

I'm sorry that you have trouble with words, but words matter. I did not say what you claimed I said.

To make it even clearer: if you're looking for portability headaches

I'm not. You are debating a straw man you invented in your head.

locations of libraries and their headers etc.

You don't need a build system for that, just use pkg-config.

And given how common autotools, for better or worse, is, I'm quite sure there's loads of other examples.

I'm not asking what you are "quite sure" of, I'm asking for actual instances of software in the real world that is checking for those precise HP-UX function signatures.

No words, point to the actual configure.ac file of the actual project.