Before #6250, the caching system was less sophisticated, but the output dir only contained build artifacts. The Zig Build System simply copied all the files from the cache directory to the output directory. However, that no longer makes sense, as demonstrated in #6510 by @FireFox317 (thanks!) which fixes a regression:
|
// The compiler can put these files into the same directory, but we don't |
|
// want to copy them over. |
|
if (mem.eql(u8, entry.name, "stage1.id") or |
|
mem.eql(u8, entry.name, "llvm-ar.id") or |
|
mem.eql(u8, entry.name, "libs.txt") or |
|
mem.eql(u8, entry.name, "builtin.zig") or |
|
mem.eql(u8, entry.name, "lld.id")) continue; |
The surrounding mechanism needs to be re-evaluated now that things work differently. For example, maybe instead of setOutputDir we want to be able to individually control the different artifacts. This would correspond to the new CLI options -femit-foo=[path] and -fno-emit-foo.
We also need to consider how --watch will integrate with the build system. That might be big enough to be a separate issue, but it is related.
Before #6250, the caching system was less sophisticated, but the output dir only contained build artifacts. The Zig Build System simply copied all the files from the cache directory to the output directory. However, that no longer makes sense, as demonstrated in #6510 by @FireFox317 (thanks!) which fixes a regression:
zig/lib/std/build.zig
Lines 2334 to 2340 in e94a06a
The surrounding mechanism needs to be re-evaluated now that things work differently. For example, maybe instead of
setOutputDirwe want to be able to individually control the different artifacts. This would correspond to the new CLI options-femit-foo=[path]and-fno-emit-foo.We also need to consider how
--watchwill integrate with the build system. That might be big enough to be a separate issue, but it is related.