CIRCLE WITH A DOT

@uecker @thephd ...
I also still think that the C/C++ build system ecosystem only has the chance of getting addressed IFF we take away responsibility from them and simplify them first. Standardizing the complexity that currently exist across all of them would just result in an even more complex generalized "solution" that really does not help at all.

@uecker @thephd Maybe partly.
I still think that removing cyclic dependencies is something to strive for in general. I see clear practical advantages for use cases that I encounter.
However, I also see problems arising from implementing too much in constexpr, but for me, the advantages from simplifying the build outweigh them clearly here. Other people might weight things differently.
...

@uecker @thephd ...
I think moving complexity into the language proper is the right approach. It frees developers from learning multiple "languages", and it simplifies porting to other platforms that require different build systems.

@uecker @thephd The reasonable approach is only have two stages, I totally agree. But this is not how any build system I know models it. They all support the complexity of arbitrary graphs, which offers enormous flexibility at the cost of unbounded complexity. Unless this gets simplified in one way or another, any build system standardization is IMHO very unlikely to happen.
...

@uecker @thephd

The build system generates input for the compiler. The compiler generates input for the build system (include dependency graph). This is cyclic, and by itself causes all sorts of complications (which are all solved in current build systems, but which IMHO makes all of them more complex than they should need to be).

This is similar to what Autoconf does (which also induces a cyclic dependency).

It is also remotely similar to what C++ Modules require (but there it is way worse).

@uecker @thephd I agree, and I think reducing the scope and responsibility of what build systems need to do, is a good and necessary step into that direction.

@uecker @thephd Well, I am happy to disagree here.

No cyclic dependency is IMHO always better than any cyclic dependency.

This whole problem tends to always bite especially hard when you need to port from one build system to another (because the existing build system does not support your platform or toolchain), like trying to use an Autoconf project with MSVC.

@uecker @thephd I am also not 100% sure that doing this in constexpr context is necessarily the best approach (mainly because debugging constexpr code is a completely unsolved problem), but it is frankly the best approach I have seen offered so far, and IMHO far better than involving the build system in any way.

@uecker @thephd If you are cross-compiling, you are running the interpreter and code generator on the build host instead of on the build target, which means, if it requires any platform-specific knowledge (like the size and alignment of fundamental types), you have to manually duplicate this knowledge into your custom interpreter.

Inside the target language itself, this information is naturally trivially available.

@uecker @thephd
make
ninja
cmake
msbuild
premake5
autotools
vcpkg
conan
apt
yum
rpm
...

Having a reverse dependency on the build system multiplies this nonsense, especially when cross-compiling and interacting between different build systems.

Compare this to any (really any) other language.

This is really not fixable if every build system invents its own mechanism for generating code at build time, thereby locking any project into build system vendor specific mechanisms.

@uecker @thephd This exact extra backwards cyclic dependency is probably the single most significant reason why building C and C++ code is hard.

@uecker @thephd https://mastodon.online/@manx/116261044523322289