Re: Grandfathering store paths considered harmful

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Am Donnerstag, dem 19.01.2023 um 15:28 +0100 schrieb Ludovic Courtès:
> Hi Liliana,
> 
> Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:
> 
> > For context, emacs uses a hash digest to more or less uniquely
> > fingerprint the version (much like guix does), so natively
> > compiling things with emacs-minimal won't speed up your packages
> > when using emacs or emacs-next and is thus next to pointless.
> 
> If emacs-minimal lacks JIT support anyway, there’s nothing it can
> compile?  Or am I missing something?
> 
> (It’s called “JIT” but we keep talking about things that need to be
> done ahead-of-time, this is confusing.  :-))
You can still do bytecode compilation, but no native code compilation.
And yes, the JIT vs. AOT distinction in Emacs is very annoying. 
Basically, we want to compile packages to native code ahead of time
using libgccjit baked into Emacs.

> > I witnessed the same type of bug in wpewebkit, which pulls in the
> > much larger webkitgtk, probably because the former uses #$output
> > rather than (assoc-ref outputs "out") in one of its phases – see
> > the attached patch for my proposed fix.
> 
> I believe the attached patch has no effect.  #$output expands to
> (getenv "out"), where "out" is an automatic environment variable of
> the derivation.
Hmm, you're right, turns out I was mistaken.  

> > If my hunch is correct, this has some further reaching
> > implications.  It means, that uses of #$output and #$(this-package-
> > input) – which we want to promote instead of labels – draw in
> > additional inputs when combined with inheritance, which in the
> > context of this thread I hope we can all agree is not good.
> 
> ‘this-package-input’ is different from #$output because it’s a purely
> host-side feature.  It refers to inputs of the package in which it
> appears; thus, if you define a package B that inherits from A, and
> the ‘arguments’ of A contain (this-package-input "whatever"), that is
> fine: B’s ‘arguments’ will refer to its own “whatever”¹.
This doesn't appear to always work, though, see bug#60831.  emacs-
minimal should really have raised an error due to missing libgccjit,
but didn't.

> Now, independent of that, it’s easy to make mistakes when using
> inheritance heavily.  The only good solution to that IMO is to avoid
> factorizing too much.  That is, in some cases, it may be more robust
> to be explicit in inherited packages—e.g., explicitly providing
> ‘inputs’ and ‘arguments’ fields—than to inherit all the fields from
> some distant parent package.
That does defeat the purposes of inheritance however.  Plus note, how
our inheritance trees are usually rather small, with one or two levels
at most.  (But of course it also affects the big compiler bootstraps
with 50 levels.)


Cheers