3 ms·
In practice it works very well though, I experimented a bit with replacing cmake with build.zig for a 'not-quite-trivial' C++ project, and tbh for cross-platfor
by flohofwoe 4y ago
In practice it works very well though, I experimented a bit with replacing cmake with build.zig for a 'not-quite-trivial' C++ project, and tbh for cross-platform code that's a lot nicer than wrestling with the arcane cmake syntax and all the C/C++ compiler toolchain differences:
https://github.com/floooh/sokol-tools/blob/master/build.zig https://github.com/floooh/sokol-tools/blob/master/build.zig
The basic idea is the same as in all other build systems: you describe your build as number of build steps and their dependencies. There's really no reason why this build description should happen in a separate build tool and language.
- humanrebar 4y agoRight. But switching build systems is a big ask for a lot of situations. The build workflow is part of the API for a lot users of that project.
- messe 4y agoJust because it’s the default doesn’t mean it’s the only option. Another approach would be to integrate your zig code as a static library, and have your existing build system call out to zig’s build system just for that part of the build. Linking it to the rest of your code could then be performed by your existing build system, just as it would link any other library. In practice, Zig is quite flexible.
- humanrebar 4y agoI'd like that plan a lot more if there were any normal way for build systems to communicate about build requirements and outcomes and the zig toolchain implemented it.
- messe 4y agoThat’s as much make’s fault as Zig. You can go further and eschew the zig build system, using `zig build-lib`, I’d that helps.