Hi, Am Sonntag, den 12.09.2021, 15:40 -0700 schrieb Sarah Morgensen: > > > + (patches > > > + (search-patches > > > + "zig-disable-libc-note-test.patch" > > Is this test really necessary to skip that test? If not, let's try > > to use the command line for that. > > We could use "-Dskip-compile-errors", but that also skips ~600 other > test cases. Point taken, let's keep it then. > > > + ;; XXX: Remove the following patch when updating LLVM > > > to 12.0.1. > > > + "zig-disable-MIPS-tests.patch" > > There's a patch for LLVM 12.0.1 waiting in the ML and we could > > potentially bump lld to 12.0.1 regardless. (Can LLVM components be > > mix-matched like that?) > > I have no idea if they *can*, but I'm pretty sure they're not > intended to be, as LLVM wants you to build everything together in one > big blob. Fair enough, I've tried to rebase this based on AndrĂ¡s patch regardless. In some sense this counts as a review of #50486, but I obviously haven't tested all the problematic packages that would keep it from being merged, like mesa. > > > + "zig-fix-cross-native-execution.patch" > > IIUC this is weaker than "-Dskip-non-native". Is there a reason to > > include specifically these non-native tests? > > Yes, as I wrote in the patch header, it fixes the behavior of 'zig > run' and 'zig test' when the target is cross-native. Would we want > to stick to upstream, even if it's buggy? I'm not particularly sure about 'zig run', but imo we should simply supply the correct linker in cross-native and not worry about upstream bugs in the negative case. > We might want to add "-Dskip-non-native" anyway as it speeds up tests > by an order of magnitude, in which case tests will succeed without > the patch. It looks their CI uses it "-Dskip-non-native" as well, > and I suppose there's not a whole lot Guix can do to mess up Zig's > cross-compiling anyway, since it's pretty self-contained... Did that. > > > + (native-search-paths > > > + (list > > > + (search-path-specification > > > + (variable "ZIG_INCLUDE_DIRS") > > > + ;; XXX: It doesn't seem as though Zig can distinguish > > > between > > > C and C++ > > > + ;; include paths, so provide both. > > > + (files '("include/c++" "include"))) > > > + (search-path-specification > > > + ;; TODO: Might be confused with "ZIG_LIB_DIR"... Maybe > > > use > > > + ;; "ZIG_INCLUDE_PATH" and "ZIG_LIBRARY_PATH"? > > > + (variable "ZIG_LIB_DIRS") > > > + (files '("lib" "lib64"))))) > > You can rewrite "zig-use-explicit-paths.patch" in-place with Emacs' > > query-replace and/or sed (or even just manually, there are no lines > > to add or remove) if you disagree with my environment variable > > naming choice. Just make sure you don't accidentally break diff by > > deleting trailing space. > > Another potential naming choice would be to prefix everything with > > ZIG_LIBC_ rather than simply ZIG_. Of course I thought about that > > only after sending my previous mail ^^" > > Ah, I meant to mention it in my last e-mail but I forgot. I didn't > want to just go changing it on you without discussing it. > > As far as I can tell, there's no such thing as a "Zig library" or a > "Zig header"; these are for including system C headers and > libraries. So, I would just go with LIBRARY_PATH and > CPLUS_INCLUDE_PATH unless we anticipate needing to tell Zig something > different than what we tell GCC/Clang. Furthermore, the in- > development 'zig cc' command is intended to be a drop-in replacement > for GCC/Clang, so it should probably honor the same environment > variables. Fair enough, I now have zig search the paths that would normally be expected to be accordingly set. This leads to doubly adding "/include", but I suppose that's fine as we risk not including the right things in a C only context otherwise. Regards