Hi Ludo,

As always, thank you for entertaining my questions!

ludo@gnu.org (Ludovic Courtès) writes:

> The Guix system string has the form ARCHITECTURE-KERNEL, because these
> are the two things not explicitly captured by the derivation graph.

I see.  When you say that something is "captured by the derivation
graph," do you mean that it is part of the hash calculation, so it
influences a derivation's store path as well as the derivation's
outputs' store paths?  I think that's what you mean, but I'd like to
make sure.  My understanding is that this is precisely the reason why we
make the Guix system string a field of each derivation: it ensures that
different systems use different store paths, which is good because an
x86_64-linux system probably can't build derivations that are intended
to be built on an armhf-linux system.

Other than the Guix system string, what things are "captured by the
derivation graph" (either explicitly or implicitly)?  For example, is
the ABI captured by the derivation graph?  What about the vendor?  What
about the executable file format (e.g., ELF vs. some other possibility)?
Anything else?

> The “hf” in “armhf-linux” denotes an ARMv7 processor with a hardware
> floating point unit; it does not denote the ABI since the ABI is
> something that’s software-defined.
>
> As it turns out, we map “armhf-linux” to the HF ABI (“eabihf”), because
> that’s the most sensible thing to do, but we could just as well map it
> to the old soft-float ABI (“eabi”).

My understanding is that when a derivation's system is "armhf-linux", it
means that the derivation itself (as opposed to its output) is intended
to be built (i.e., the derivation's builder is intended to be run) on
the "armhf-linux" platform.  If the Guix system string does not contain
details like the ABI, then how does Guix differentiate between the case
in which the derivation is built on an ARM system that uses the HF ABI,
and the case in which it is built on an ARM system that uses the
soft-float ABI?  Are you saying that we should expect the derivation to
build correctly and produce the same output regardless of which ABI is
used?  Or is there some other mechanism by which Guix differentiates
these two cases that I am not aware of?

>> My understanding is that multiple GNU triplets can refer to the same
>> platform.  For example, I believe "arm-linux-gnueabihf" is the same as
>> "arm-unknown-linux-gnueabihf" because config.sub in Autoconf translates
>> the former to the latter.  Do they refer to the same platform?
>
> Usually yes, because user-land software doesn’t care about the “vendor”
> part.  It could make a difference to, say, GRUB, for which the “vendor”
> part is important.

What is the recommended way to package software in Guix when the
software's behavior or the output of the derivation that builds it can
be influenced by the value of the "vendor" part?

For example, suppose I purchase an x86_64-linux server from a vendor
called FooCorp specifically so that I can take advantage of some super
cool feature of a piece of software that has been packaged in Guix.  It
would be unfortunate if I installed that software using a substitute
from Hydra, only to find that the super cool feature does not work on my
FooCorp machine because the software was not explicitly compiled for the
x86_64-foocorp-linux-gnu platform.  This is probably a theoretical edge
case, but I'm curious to know what the plan is for dealing with
situations like this.

> Guix doesn’t try to interpret GNU triplets in any way.  So when you pass
> a triplet to --target, it goes ahead and creates a cross-toolchain for
> that triplet.
>
> If turns out that Hydra has substitutes for the arm-linux-gnueabihf
> cross-toolchain, but not for arm-whatever-linux-gnueabihf.

I see.  That makes sense.

> The triplet idea predates GNU/Linux, I think.  Back then, it was quite
> clear what the OS was: SunOS, AIX, GNU, etc.
>
> With glibc ported to the kernel Linux, it became useful to differentiate
> between “gnu” (i.e., GNU/Hurd) and “linux-gnu”.  User-land software
> often only cares about the “-gnu” part, but sometimes it needs to know
> about the kernel as well.
>
> Then people had the idea to abuse the triplet to piggyback information
> about the ABI being targeted.  There are bits in the toolchain that
> interpret it meaningfully.
>
> I hope it makes sense.  :-)

Yes, I understand.  The GNU triplet concept makes more sense to me now.
However, if information like the vendor and the OS/ABI are important
enough to put into the GNU triplet, I still don't understand why we can
get away with omitting those details from the Guix system string.

Hopefully you can help me to understand what I'm missing.

-- 
Chris