5 ms·

Honestly, the lack of separation of concerns between compiling, linking, building, and packaging is what gives me pause about zig. I don't see it having a nice

Honestly, the lack of separation of concerns between compiling, linking, building, and packaging is what gives me pause about zig. I don't see it having a nice onramp for my existing C and C++ codebases. It's trying to make a new systems programming ecosystem, sort of, but also trying to interop well with C source code but not at the tooling level... not exactly a coherent adoption curve.

naasking 4y ago
Is this onramp problem an actual issue you've run into or a speculative issue that you anticipate but haven't actually tried?
- humanrebar 4y ago
  I don't have a repo that demonstrates now, no. But it's dismissive to call it speculative. I've seen this sort of problem in smaller situations in the past, like projects whose build systems assume toolchains that aren't what are used in my packaging ecosystem. Replacing all my compilers and linkers and build systems is at least an order of magnitude more disruptive than that.
  - deleted 4y ago
    [deleted]
  - naasking 4y ago
    I have no dog in this race as I don't use Zig at the moment, but I'm not sure speculative is that unfair. Zig can literally be a drop-in replacement for GCC/clang [1], meaning you don't even have to fully adopt Zig as the build tool, so your initial comment about a lack of separation of concerns doesn't seem correct: just use "zig cc" for the C/C++ source if that's all you want. That said, using Zig as the build tool seems to bring trivial cross-compilation support and portability, without having to deal with linkers [2]. Cross-compilation has always been and remains a PITA, so that's pretty compelling. [1] https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace... [2] https://zig.news/kristoff/compile-a-c-c-project-with-zig-368j https://zig.news/kristoff/compile-a-c-c-project-with-zig-368...
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 ago
  Right. 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 ago
    Just 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 ago
      I'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 ago
        That’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.

naasking 4y ago

Is this onramp problem an actual issue you've run into or a speculative issue that you anticipate but haven't actually tried?

humanrebar 4y ago
I don't have a repo that demonstrates now, no. But it's dismissive to call it speculative. I've seen this sort of problem in smaller situations in the past, like projects whose build systems assume toolchains that aren't what are used in my packaging ecosystem. Replacing all my compilers and linkers and build systems is at least an order of magnitude more disruptive than that.
- deleted 4y ago
  [deleted]
- naasking 4y ago
  I have no dog in this race as I don't use Zig at the moment, but I'm not sure speculative is that unfair. Zig can literally be a drop-in replacement for GCC/clang [1], meaning you don't even have to fully adopt Zig as the build tool, so your initial comment about a lack of separation of concerns doesn't seem correct: just use "zig cc" for the C/C++ source if that's all you want. That said, using Zig as the build tool seems to bring trivial cross-compilation support and portability, without having to deal with linkers [2]. Cross-compilation has always been and remains a PITA, so that's pretty compelling. [1] https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace... [2] https://zig.news/kristoff/compile-a-c-c-project-with-zig-368j https://zig.news/kristoff/compile-a-c-c-project-with-zig-368...

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 ago
Right. 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 ago
  Just 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 ago
    I'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 ago
      That’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.