[bug#50449] [bug#47006] [WIP PATCH v2 2/2] gnu: Add zig.

[Sarah Morgensen]

Hi Liliana,

I just thought I'd send a note that lld (and the LLVM toolchain) is now
12.0.1 in master (see a7283c1d14).

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> 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
>
> [2. text/x-patch; v4-0001-gnu-lld-Update-to-12.0.1.patch]...
>
> [3. text/x-patch; v4-0002-gnu-Add-zig.patch]...

--
Sarah