[bug#74253] [PATCH] transformations: Add multituned-package.

[Efraim Flashner <efraim@flashner.co.il>]

[-- Attachment #1: Type: text/plain, Size: 3290 bytes --]

On Tue, Nov 12, 2024 at 11:31:57AM +0100, Ludovic Courtès wrote:
> Hi,
> 
> Efraim Flashner <efraim@flashner.co.il> skribis:
> 
> > * guix/transformations.scm (package-tuned-for-psabi,
> > multituned-package): New variables.
> >
> > Change-Id: I09ac7ae9fc2bcd9aa712b3c30fef807bc7d55895
> > ---
> >
> > This allows wrapping a package definition in multituned-package, ie:
> >
> > (define-public opus
> >  (multituned-package
> >   (package
> >    ...)))
> >
> > I'm not sure where to go with this patch from here. This will provide
> > the psabi libraries for x86_64 and powerpc64le so they get most of the
> > benefits from tuning for the architecture but without needing to specify
> > which architecture to tune for.  It should also provide a nice boost for
> > guix packs and docker images and the like.
> >
> > The downside with using this by default is the larger package size due
> > to the extra versions of the libraries, and if it is used then the
> > regular --tune is disabled for that package.
> >
> > I think adding it as a '--tune=generic' or '--tune=psabi' would be a
> > nice way to use it.
> 
> Should that be a package transformation though?  Could we instead have a
> build system trick or the ‘multituned-package’ procedure exposed so
> build the package several times and fill in lib/glibc-hwcaps?

I figured (guix transformations) worked well since it was using an
existing transformation to generate the different variants.

I'm not sure what you mean by a build system trick, like build the
package multiple times in one like with x265?

This exposes the multituned-package procedure (looks like I mistyped in
the commit message) which takes a package and can be just added on top
of an existing package definition, like hidden-package can.

> That way, packagers would explicitly choose this technique for select
> packages, which would then no longer need the ‘tunable?’ property.

Something like a flag in the build-system like #:tests? is? Or like a
package property?

> The question becomes: how would we choose which packages is eligible to
> this technique as opposed to ‘--tune’?  Intuitively, I would use that
> for general-purpose packages like ‘opus’, but keep ‘--tune’ for more
> niche/scientific packages.

Unfortunately I think just like with choosing what to do with tunable?
we end up in the same spot deciding somewhat arbitrarily what to provide
the psabi options for and what not to.

> WDYT?
> 
> Thanks,
> Ludo’.

Looking more at the patch I've remembered that I've only taken care of
the gnu- and cmake- build-systems.  I was going to add about tuning the
package on other architectures, like aarch64, but it seems I fixed that
already.

If it were just the configure-flags and the post-installation removal of
files then I could see trying to make something that could be inserted
manually into specific packages, but the whole thing rests on the
tuned-package procedure actually producing libraries tuned for the
different psABIs.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]