Autodafe 0.2 Released For Freeing Your Project From Autotools

[billyswong]

You never worked with C and C++, did you? Nobody talks about package manager and automatic downloads. You have to work with C libraries, that have some common parts and other parts are different. Linux uses glibc, macOS and BSD something different, and Windows has its own ways. C++ has three mayor compilers (GCC, Clang, MS Visual C++) and you have to work with multiple different version. Compiling Boost is non-trivial. On super computers you have to use the MPI implementation provided by the super computer vendor.
Now go play with JavaScript, Python, or whatever toy you prefer.

This shows how C/C++ stinks. Creating compiler portable + OS portable source code shouldn't become a job of scripting outside the main code. I remember there is pre-compiler macro in C that can do a lot of string substitution and also #ifdef etc. One may also use wrapper function calls. All these shall be enough to handle incompatible OS/platform/distributions libraries.

About where the libraries are located, this shouldn't be a part of the program project code unless the library is part of the project itself and written within. External libraries location should have been a job of the development environment and be handled by the development environment. It shouldn't be scripted and carried by each individual software projects. if a compiler or a platform needs wrapper script, it should be done per compiler, per platform, not per software project.

[kpedersen]

It is because I work with boomer trash such as C++ and Autotools that I want something better.

Gosh, you must really hate... computers. Almost everything in them and on them is written by our boomer forefathers.

Bet you also hate the housing market too?

[mathletic]

This shows how C/C++ stinks. Creating compiler portable + OS portable source code shouldn't become a job of scripting outside the main code

Human mankind has two answer to this:

1. Even the C and C++ committees relented and offer sind C17 and C++17 feature macros indicating the availability of modern features. They screwed three years later with C++ modules relying on proper build system support.
2. Rebuild it in Rust.

[ziguana]

Gosh, you must really hate... computers. Almost everything in them and on them is written by our boomer forefathers.

Bet you also hate the housing market too?

What can I say, the fella came at me. I am having trouble thinking of a build system that I do like though. I guess meson is nice, and bazel (when you have a monorepo). Some days when I have to dig through makefiles, I do have an urge to buy a cabin in Montana and write a manifesto.

Regarding boomers, they solved their problems with the tools that they had. However, we should no longer need Autotools, and C++ would be a better language if it could shed its legacy features and some compatibility guarantees. I used to be a fan, but no longer have the will to keep up with its churn.

[billyswong]

Human mankind has two answer to this:

1. Even the C and C++ committees relented and offer sind C17 and C++17 feature macros indicating the availability of modern features. They screwed three years later with C++ modules relying on proper build system support.
2. Rebuild it in Rust.

Imagine a MS Word file that can't tell itself which version of MS Word it needs for the file to be opened correctly. Or a MS Office suite version that can't tell users a file contains features newer than what it supports. It is plainly stupid.

[mathletic]

The author of Meson shared some thoughts regarding how Autotools' off-putting endangers open source projects.

https://nibblestew.blogspot.com/2024/04/aesthetics-matter.html

[felipec]

Just wait for a bit though... CMake and meson are as easy to abuse in ways that are nearly as obscure BTW.

Go ahead and actually do it. Try to introduce the xz backdoor in xz's CMake build system.

There's nothing on god's green Earth more convoluted and obfuscated than the scripts autotools generates.

If you think the obfuscated patch in autotools is equally obfuscated in CMake, then show us.

Talk is cheap.

[jabl]

There should not be any detection of the build environment, which every package would do in a subtly different way. It is the job of the package manager to provide a build environment with all the dependencies and flags. If something required is missing, the build should immediately FAIL, not try to download missing dependencies, and not try workarounds such as linking against some other libraries.

The reason that reproducible builds and cross compilation are so painful is because of pushing of these packaging concerns to individual builds. It's not every developer's job to figure out what's present or absent on the target system. The autotools approach is from the stone age period of dependency management, and we have better tools now.

I'm confused by what is being proposed here. Say I want to create a piece of software that uses the POSIX function foo(), typically implemented in libc. Unfortunately it turns out that BlubOS <= 8 has foo, but with a different function signature than what POSIX and GNU libc provide. If I'm not allowed to use some kind of tool to investigate the compile host at build time like autoconf, or the equivalent functionality in cmake, meson, or other build systems, what should I do?

And no, I don't want to hardcode into my build system that BlubOS provides foo() with a different prototype, as I don't use BlubOS myself I don't want to keep track of whether BlubOS 9.0 finally fixes the bug by changing the foo() signature, and I should thus update my version checking logic in my build.

Running a piece of software in a Ubuntu 14.10 docker container because that's the OS the developer happened to use when the software was last modified? Might work, for some definition of work, but ugh.

[felipec]

Unfortunately it turns out that BlubOS <= 8 has foo, but with a different function signature than what POSIX and GNU libc provide.

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.

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.

[ziguana]

I'm confused by what is being proposed here. Say I want to create a piece of software that uses the POSIX function foo(), typically implemented in libc. Unfortunately it turns out that BlubOS <= 8 has foo, but with a different function signature than what POSIX and GNU libc provide. If I'm not allowed to use some kind of tool to investigate the compile host at build time like autoconf, or the equivalent functionality in cmake, meson, or other build systems, what should I do?

And no, I don't want to hardcode into my build system that BlubOS provides foo() with a different prototype, as I don't use BlubOS myself I don't want to keep track of whether BlubOS 9.0 finally fixes the bug by changing the foo() signature, and I should thus update my version checking logic in my build.

Running a piece of software in a Ubuntu 14.10 docker container because that's the OS the developer happened to use when the software was last modified? Might work, for some definition of work, but ugh.

It sounds like you don't think it's worth the maintenance cost to support BlubOS <= 8 here, so don't. 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.