A r e y o u r e a d y t o h a v e s o m e f u n ?
-
@uecker If that's all you took from this, okay!
@thephd @uecker take a look at fftw3’s build system and i think several use cases for this kind of compile-time functionality will become apparrent. for example, it currently uses some arcane OCaml code generators to turn customizable rules into SIMD code. it’s so unwieldy that the project’s README recommends users only ever build from tarballs with the sources already generated.
(after exchanging some emails i ported that whole mess to meson to make it usable but then that didn’t get reviewed at all and i stopped caring) -
@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 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.
@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 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.
-
@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.
@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.
-
@thephd @uecker take a look at fftw3’s build system and i think several use cases for this kind of compile-time functionality will become apparrent. for example, it currently uses some arcane OCaml code generators to turn customizable rules into SIMD code. it’s so unwieldy that the project’s README recommends users only ever build from tarballs with the sources already generated.
(after exchanging some emails i ported that whole mess to meson to make it usable but then that didn’t get reviewed at all and i stopped caring) -
@thephd @uecker take a look at fftw3’s build system and i think several use cases for this kind of compile-time functionality will become apparrent. for example, it currently uses some arcane OCaml code generators to turn customizable rules into SIMD code. it’s so unwieldy that the project’s README recommends users only ever build from tarballs with the sources already generated.
(after exchanging some emails i ported that whole mess to meson to make it usable but then that didn’t get reviewed at all and i stopped caring) -
-
@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. )
-
@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.
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).
-
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).
@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. )
@uecker @thephd that’s just cmake being utter garbage (without hyperbole, it has more in common with microsoft batch than it does with an actual build system) that for no apparent reason half the software industry agreed to force on each other, the other half being google’s flavor of the week.
qt needs more than 90k lines of code—again, no hyperbole because i’ve ported some of that recently—consisting mostly of cmake workarounds to achieve what meson can express entirely declaratively in just over a hundred. and none of it would have to exist if qt didn’t require 5 or 6 different generators.
so i don’t think “this makes bad build systems even more of a pain to use” is a strong argument -
@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.
@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 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.
... -
@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 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?
@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 that’s just cmake being utter garbage (without hyperbole, it has more in common with microsoft batch than it does with an actual build system) that for no apparent reason half the software industry agreed to force on each other, the other half being google’s flavor of the week.
qt needs more than 90k lines of code—again, no hyperbole because i’ve ported some of that recently—consisting mostly of cmake workarounds to achieve what meson can express entirely declaratively in just over a hundred. and none of it would have to exist if qt didn’t require 5 or 6 different generators.
so i don’t think “this makes bad build systems even more of a pain to use” is a strong argument -
@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 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 meson can also handle that case (plus cross compilation and figuring out how to run it if it needs to compiled for a different system/architecture) in a single line as well.
but you’ve just said it: cross-compilation breaks the assumptions of many build systems. there aren’t many that properly support the canadian cross to begin with, and there’s a lot of platform-specific quirks that build systems need to figure out to make it all work as well.
that’s an incredible amount of jank and moving parts for something that could just be done by the compiler that you already use to compile the generator code.
