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 @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
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.
@manx I agree that the lack of standardization of build systems is a problem.
-
@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 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.
-
@manx I agree that the lack of standardization of build systems is a problem.
@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.
-
@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 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.
...
