[gentoo-dev] rfc: native multilib support in portage for eapi 7

[gentoo-dev] rfc: native multilib support in portage for eapi 7

[William Hubbs]

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

All,

I find the multilib eclasses and their separate multilib phase functions
to be confusing, so I was wondering if we could discuss making multilib
support native to portage in eapi 7 so that we can use the normal phase
functions again?

Thanks,

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] rfc: native multilib support in portage for eapi 7

[Michał Górny]

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

On Tue, 1 Dec 2015 11:38:08 -0600
William Hubbs <williamh@gentoo.org> wrote:

> I find the multilib eclasses and their separate multilib phase functions
> to be confusing, so I was wondering if we could discuss making multilib
> support native to portage in eapi 7 so that we can use the normal phase
> functions again?

That won't help you since the in-spec support would require special
phase functions anyway.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] rfc: native multilib support in portage for eapi 7

[Gregory M. Turner]

On Tue, 2015-12-01 at 18:45 +0100, Michał Górny wrote:
> On Tue, 1 Dec 2015 11:38:08 -0600
> William Hubbs <williamh@gentoo.org> wrote:
> 
> > I find the multilib eclasses and their separate multilib phase
> > functions
> > to be confusing, so I was wondering if we could discuss making
> > multilib
> > support native to portage in eapi 7 so that we can use the normal
> > phase
> > functions again?
> 
> That won't help you since the in-spec support would require special
> phase functions anyway.

It might help with other things, though.  I think it might be hard to
build sufficient consensus around this, but, if we could do so, it
could really be a boon.

As I recently pointed out in another thread, if we had a really easy-
to-use, high-performing dedicated vdb feature behind "multi-ness," we
might realize all kinds of benefits.

For example -- of course the following are hoplessly speculative but
just humor me for a moment -- in a sufficiently flexible
implementation, concievably things like prefix and crossdev could be
normalized as, respectively, user-configurable "EPREFIX" and "target"
"multi-" dimensions.

Not saying they should be, though, just making the point that the
concievable applications of a feature tend to correspond to the
feature's limitations and strengths from a practical perspective, and
our current multi- eclass frameworks are fairly limited in precisely
that way, despite being tremendously clever solutions to a very
difficult problem.

-gmt

Re: [gentoo-dev] rfc: native multilib support in portage for eapi 7

[Alexis Ballier]

On Tue, 1 Dec 2015 18:45:20 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> On Tue, 1 Dec 2015 11:38:08 -0600
> William Hubbs <williamh@gentoo.org> wrote:
> 
> > I find the multilib eclasses and their separate multilib phase
> > functions to be confusing, so I was wondering if we could discuss
> > making multilib support native to portage in eapi 7 so that we can
> > use the normal phase functions again?  
> 
> That won't help you since the in-spec support would require special
> phase functions anyway.


Not really. PM can call something like 'multilib_foreach_abi
src_compile'. This would actually simplify stacking: e.g. cmake +
multilib wouldnt require an extra eclass.

Re: [gentoo-dev] rfc: native multilib support in portage for eapi 7

[Mike Frysinger]

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

On 01 Dec 2015 11:38, William Hubbs wrote:
> I find the multilib eclasses and their separate multilib phase functions
> to be confusing, so I was wondering if we could discuss making multilib
> support native to portage in eapi 7 so that we can use the normal phase
> functions again?

we cannot hardcode the actual ABIs in PMS because adding/removing ones
would require an EAPI update which is a terrible idea

i don't see a benefit in adding the helper/phase functions either and
wouldn't actually address your concern: you'd still need to know the
API and how to use them.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] rfc: native multilib support in portage for eapi 7

[Alexis Ballier]

On Wed, 2 Dec 2015 12:43:22 -0500
Mike Frysinger <vapier@gentoo.org> wrote:

> On 01 Dec 2015 11:38, William Hubbs wrote:
> > I find the multilib eclasses and their separate multilib phase
> > functions to be confusing, so I was wondering if we could discuss
> > making multilib support native to portage in eapi 7 so that we can
> > use the normal phase functions again?  
> 
> we cannot hardcode the actual ABIs in PMS because adding/removing ones
> would require an EAPI update which is a terrible idea

nothing prevents defining the ABIs in profiles

a line has to be drawn and well thought of; whether it's worth the
effort, I doubt it

however, considering this would make the multilib-portage & multilib
eclasses ideas converge and with the recent trends in including the
kitchen sink in PMS, it's not something to discard completely