CIRCLE WITH A DOT

@mia The unpleasant experiences I had are not with projects doing run-time code generation by running a program during the build, but were all related to other random build complexities.

@mia @thephd You argument is "build systems are a mess, so solve everything in the compiler close to the source of the problem". Somehow this argument is also seems weak. Similar generic arguments always are used to justify centralization of complexity. But I do think code generation is fundamentally different from code translation and should not be done by the same tool and I do not think this is purely aesthetic argument. But let's agree to disagree.

@mia @thephd I do not agree that the solution needs to be ugly hacks. I simply do not see why putting the complexity into the language and the compiler is a step to overall improvement. I think it does the opposite.

@mia @thephd I think "just" having an additional interpreter in the compiler is not generally a good idea. I want things to be more modular and less monolithic. Compilers are already too complex for my taste. If people use modularity to create a mess, then this is IMHO not an argument against modularity but for cleaning up the mess.

@mia @thephd I certainly agree that CMake is just bad independently of constexpr. I haven't looked at meson much, but if I needed to build and run a C program to create specialized code it would be a single line in my Makefile. Cross-compilation would be more complicated though.

@manx @thephd Maybe you are right, but my perspective after observing the industry for a while is this: Complexity always grows until things suck too much and then people build alternatives and the cycle starts again. At the same time, if some part does not suck yet because it is relatively small and simple, people think that complexity needs to be moved there from the other parts nobody wants to touch. Couldn't this be part of what is happening here?

@manx @thephd Thanks! I guess in a reasonable approach you would only have two stages. You build a tool that creates the code you then run to create he code you ultimately compile. This is not fundamentally different to what happens with constexpr. Just there is all part of an in transparent and slow monolithic C++ compiler. The complexity is not gone, but just hidden. But this is not better IMHO.

@mia @thephd (my personal pain with build systems is typically with CMake where it throws some error and I have no idea where in the thousands of lines of CMake I am supposed to change something. Especially if it first compiles for a long time and processing constexpr as part of it just makes it worse. )

@mia @thephd Then let's agree to disagree, because my opinion is that compilers should not be misused as interpreters.

@mia @thephd I don't know. Maybe fftw3's build system could be better, but I personally would not prefer a C++ constexpr approach to it.

@manx @thephd I am not entirely sure I understand what is "cyclic" in this context. To me one reason people try to make languages into complete frameworks is that it seems an easier approach to standardize things at the language level than try to harmonize the diverse environments. And this is a valid argument, but not really a technical one.

@manx @thephd IMHO if people are unhappy about build systems (which seems to be the case and there are certainly good reasons), one should think hard why this is the case and fix it at that level. This is hard, because it is likely not just a technical issue, but lack of standardization and the need to support annoying environments that intentionally wanted to be different.

@manx @thephd Cross-compilation is a good argument, but it is still not clear to me that this would not be better solved at a different level.

@manx But I think it partially also reflects the size of the ecosystem. I really do not like many other languages that provide a framework that locks you into a specific way of doing things.

@manx I agree that the lack of standardization of build systems is a problem.

@manx @thephd You could turn this around "Do not feel proud about your clever compile-time meta programming. You should feel ashamed that you have been tricked into using your compiler as a poor interpreter."

@manx @thephd Can you explain what you mean? I do not generally find building C code hard - not even when it runs code (which it rarely does).

@thephd Ok, but why does it need to be solved by compile-time interpretation and not simply be a tool one runs during built? To me, this seems to solve the problem at the wrong place and using poorly suited tools (a compiler is not a good interpreter). And my only explanation so far is that people are nerd-sniped into doing it.

@thephd What I do not understand is why the extra build step is a problem.

@thephd Cool, but why?