Apart from complexity, are there technical barriers to have a "crossplatform autotools"?

I'm asking out of curiosity. If this kind of question is not welcome, please let me know.

I am aware of the autotools stack and its problems, but one major, albeit theoretical benefit of them is that if used correctly, the resulting configure script that will be distributed with a so-called tarball only needs a POSIX shell to detect dependencies on the target system itself and generate a Makefile. Nowadays, there exists CMake which solves many problems, but at the cost of the end user having to install it on their system, which is not always convenient. (e.g. when bootstrapping one doesn't yet have CMake but has a shell).

Is there a technical reason that prevents having a "cross-platform autotools"? By this I mean a tool that:

• generates standalone scripts which do the same checks that CMake does
• which are written in the target's shell language
• and generate the target's build files

(e.g. the result is standalone POSIX shell script that generates POSIX makefile, batch/PowerShell that generates Visual Studio solution). These could be generated for all supported platforms of a project, and one would tell the end user to run the script for their OS and platform, no need to install anything else than the compiler and dependencies.

My suspicion is that the reason something like this doesn't exist is not technical but rather due to 1) complexity and 2) CMake solves most of the problems already. Is there any other reason I'm missing?

> Is there a technical reason that prevents having a "cross-platform
> autotools"? By this I mean a tool that:
>
> - generates standalone scripts which do the same checks that CMake does
> - which are written in the target's shell language
> - and generate the target's build files

TL;DR: Prevents, no. Disfavors, yes.

The Autotools are cross-platform. Their whole point is that Unix-like systems vary significantly on both per-arch/OS and per-system bases, and the Autotools provide an adaptive build system flexible enough in principle to support a diversity of platforms. That certainly includes MacOS, and to some extent it even includes Windows (with mingw / msys2, for example). Even if it were limited to just POSIX-conforming systems, these are sufficiently diverse that that would still be cross-platform.

Anyway, the first challenge here is to choose what commonalities to depend upon. The Autotools and CMake diverge here. The Autotools choose a POSIX shell and minimal set of command-line tools as the common components. CMake chooses a bespoke language. Other alternatives choose Python or Java or another general-purpose programming language. Any way around, these systems depend first and foremost on the needed language implementation to be provided by the build environments where they will be used. You say there's no cmake binary for NewOS 23? Then no CMake for you on machines running that.

The second challenge is to express the needed configuration checks and the needed build rules in a way that can be adapted to the full diversity of systems that are to be supported. This is where CMake's choice of a bespoke language covering both of these areas shines most. In principle, however, any language with sufficient power could be chosen, and translated as needed to languages appropriate to various systems. Or one can choose a general-purpose language and limit build systems to those providing an implementation of that language.

But the crux of the matter may be timing. If you are going to generate scripts in the multiple native shell languages of a variety of targets, then when do you do that? If you wait until build time then why bother? Instead of writing a program that generates appropriately-targeted shell scripts at that point, wouldn't it be cleaner and simpler to write a program that directly manages the build? On the other hand, if you are going to build targeted scripts as a project maintenance activity then the maintainer or the tools need to make a decision at that time about what platforms are supported.

Overall, a tool such as you describe is possible in principle, but I don't see why anyone would choose to build something with that particular combination of design elements.

> My suspicion is that the reason something like this doesn't exist is not technical but rather due to 1) complexity and 2) CMake solves most of the problems already. Is there any other reason I'm missing?

I agree that the reason is not technical. I suppose that complexity factors in, but I don't think we're looking at something with a different order of complexity than CMake. The main issue here is that combination of characteristics you describe makes for a bad design.

As an alternative, consider (just for the sake of argument) something like SCons.^* It does or can do system configuration checks such as CMake and Autotools configure scripts do, and it manages actual builds as CMake-generated build systems and Autotools-generated makefiles do. It is cross-platform in the sense that it runs on any platform supporting new-enough Python (not a native shell script) and that additionally provides a toolchain it knows about, whether natively or through custom additional configuration.

^*I despise SCons, but it fits into this discussion.