guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Liliana Marie Prikler
Subject: [bug#47006] [WIP PATCH v2 2/2] gnu: Add zig.
Date: Tue, 14 Sep 2021 18:17:14 +0200
User-agent: Evolution 3.34.2

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

Attachment: v4-0001-gnu-lld-Update-to-12.0.1.patch
Description: Text Data

Attachment: v4-0002-gnu-Add-zig.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]