A r e y o u r e a d y t o h a v e s o m e f u n ?
-
Ultimately, this means we can process files -- recursively -- at compile-time, meaning that rather than embedded shaders with
#includes that can't be touched, we can process those includes and make true single blobs without extra build steps.compile-time python with imports is VERY possible.
@thephd Cool, but why?
-
Ultimately, this means we can process files -- recursively -- at compile-time, meaning that rather than embedded shaders with
#includes that can't be touched, we can process those includes and make true single blobs without extra build steps.compile-time python with imports is VERY possible.
@thephd whoa.gif
-
@thephd Cool, but why?
@uecker C++ has capabilities that can make great use of this. A perfect example is using (Generative) reflection to generate, at compile-time, the perfect FFI that maps to Python, or Lua, or JavaScript, with all of the utility that comes from having it mapped perfectly to C(++) interfaces and fully type-checked while always being generated directly from said Lua or Python or JavaScript source code.
This also applies to things like e.g. Rust and C++ interop, which has also been the topic of discussion and monetary investment. (Not that they're paying me; I wish they would, I could do a lot more for them than just
std::embed.)C doesn't have the systems in place to do things like this, so in most cases they'd just have to rely on the usual techniques used today: code generators, hand-written parsers, fresh data files and description files used to drive code generation (like e.g. SWIG). Certainly not bad, but not nearly as "automated luxury FFI" as C++ can make it.
-
@uecker C++ has capabilities that can make great use of this. A perfect example is using (Generative) reflection to generate, at compile-time, the perfect FFI that maps to Python, or Lua, or JavaScript, with all of the utility that comes from having it mapped perfectly to C(++) interfaces and fully type-checked while always being generated directly from said Lua or Python or JavaScript source code.
This also applies to things like e.g. Rust and C++ interop, which has also been the topic of discussion and monetary investment. (Not that they're paying me; I wish they would, I could do a lot more for them than just
std::embed.)C doesn't have the systems in place to do things like this, so in most cases they'd just have to rely on the usual techniques used today: code generators, hand-written parsers, fresh data files and description files used to drive code generation (like e.g. SWIG). Certainly not bad, but not nearly as "automated luxury FFI" as C++ can make it.
@thephd What I do not understand is why the extra build step is a problem.
-
@thephd What I do not understand is why the extra build step is a problem.
@uecker I don't think the extra build step is the problem. I think the ability to e.g. parse C++ or C code and generate the proper FFI to connect to other languages, or vice versa, is a tooling investment that isn't really a fully solved problem.
-
@uecker I don't think the extra build step is the problem. I think the ability to e.g. parse C++ or C code and generate the proper FFI to connect to other languages, or vice versa, is a tooling investment that isn't really a fully solved problem.
@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 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.
@uecker If that's all you took from this, okay!
-
@thephd What I do not understand is why the extra build step 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
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.
