[gentoo-dev] multilib clean up

[gentoo-dev] multilib clean up

[Mike Frysinger]

i plan on punting these (hardly used) functions from the
multilib.eclass (once the handful of open bugs are closed):
  get_ml_incdir
  prep_ml_includes
  create_ml_includes
  create_ml_includes-absolute
  create_ml_includes-tidy_path
  create_ml_includes-listdirs
  create_ml_includes-makedestdirs
  create_ml_includes-allfiles
  create_ml_includes-sym_for_dir
further, the CDEFINE_xxx multilib vars will go with them

for the most part, these were really only used by the glibc ebuilds.
for the ones that dont support multilib natively (and necessitated
these funcs in the first place), i'll simply punt the ebuilds.  this
will probably be just the glibc-2.5 ebuilds for now.

also, i'll be converting the glibc ebuilds do always invoke the
multilib_env helper functions.  this will allow us to drop the
{C,LD}FLAGS_xxx and friends from profiles since glibc was the main
consumer.  i imagine this inadvertently break some other packages, so
if people want to test this on their own systems before i make the
commit, that'd be cool.  the plan would be for said breakage will go
through bugzilla to get the ebuild updated rather than reverting the
profile.
-mike

Re: [gentoo-dev] multilib clean up

[Thomas Sachau]

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

Am 07.03.2011 11:24, schrieb Mike Frysinger:
> i plan on punting these (hardly used) functions from the
> multilib.eclass (once the handful of open bugs are closed):
>   get_ml_incdir
>   prep_ml_includes
>   create_ml_includes
>   create_ml_includes-absolute
>   create_ml_includes-tidy_path
>   create_ml_includes-listdirs
>   create_ml_includes-makedestdirs
>   create_ml_includes-allfiles
>   create_ml_includes-sym_for_dir
> further, the CDEFINE_xxx multilib vars will go with them
> 
> for the most part, these were really only used by the glibc ebuilds.
> for the ones that dont support multilib natively (and necessitated
> these funcs in the first place), i'll simply punt the ebuilds.  this
> will probably be just the glibc-2.5 ebuilds for now.
> 
> also, i'll be converting the glibc ebuilds do always invoke the
> multilib_env helper functions.  this will allow us to drop the
> {C,LD}FLAGS_xxx and friends from profiles since glibc was the main
> consumer.  i imagine this inadvertently break some other packages, so
> if people want to test this on their own systems before i make the
> commit, that'd be cool.  the plan would be for said breakage will go
> through bugzilla to get the ebuild updated rather than reverting the
> profile.
> -mike
> 
> 

Please leave those vars in the profile, i depend on them in multilib-portage to crosscompile e.g.
for x86 on the amd64 profile. If you remove them now, they would be re-added again once
multilib-portage (and the related EAPI) become official, so imho we can just leave them in for now.

-- 
Thomas Sachau

Gentoo Linux Developer


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

Re: [gentoo-dev] multilib clean up

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1253 bytes --]

On Monday, March 07, 2011 12:35:53 Thomas Sachau wrote:
> Am 07.03.2011 11:24, schrieb Mike Frysinger:
> > also, i'll be converting the glibc ebuilds do always invoke the
> > multilib_env helper functions.  this will allow us to drop the
> > {C,LD}FLAGS_xxx and friends from profiles since glibc was the main
> > consumer.  i imagine this inadvertently break some other packages, so
> > if people want to test this on their own systems before i make the
> > commit, that'd be cool.  the plan would be for said breakage will go
> > through bugzilla to get the ebuild updated rather than reverting the
> > profile.
> 
> Please leave those vars in the profile, i depend on them in
> multilib-portage to crosscompile e.g. for x86 on the amd64 profile. If you
> remove them now, they would be re-added again once multilib-portage (and
> the related EAPI) become official, so imho we can just leave them in for
> now.

these need to be centralized somehow.  duplicating multilib.eclass and the 
profiles indefinitely isnt going to fly.

perhaps we unify all the multilib settings into one file such as 
base/make.defaults ... that would require normalizing of the ABI value across 
all targets, but i dont think that's an issue.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: multilib clean up

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 894 bytes --]

the next tweak i'll be making is the order of paths returned by 
get_all_libdirs.  it guarantees "lib" to always be in the list and it does 
this simply by having it be the first item.  i cant see this position being a 
hard requirement, just a coding convenience, and it's desirable to have the 
paths follow the actual ABI dir preferences (e.g. Bug 357225).

so the new code will return paths according to the MULTILIB_ABIS order, and 
then append "lib" only if it hasnt already been posted.  assumption here is 
that "lib" is only showing up if people want to symlink or otherwise fake it, 
and so prefer the native paths first.

in looking at the few packages that actually use this function, i cant see any 
problems.  it's used to set up search paths and preferring the "faked" dir 
over the real dir, or even a diff ABI over the active ABI, shouldn't be an 
issue.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: multilib clean up

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 215 bytes --]

gcc-config-1.5 will no longer implicitly append CFLAGS_<abi> to the compile.  
this should be unnecessary now that multilib.eclass and glibc add the required 
multilib flags explicitly to CC/CFLAGS/etc...
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: multilib clean up

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 524 bytes --]

On Monday, March 07, 2011 05:24:29 Mike Frysinger wrote:
> i plan on punting these (hardly used) functions from the
> multilib.eclass (once the handful of open bugs are closed):
>   get_ml_incdir
>   prep_ml_includes
>   create_ml_includes
>   create_ml_includes-absolute
>   create_ml_includes-tidy_path
>   create_ml_includes-listdirs
>   create_ml_includes-makedestdirs
>   create_ml_includes-allfiles
>   create_ml_includes-sym_for_dir
> further, the CDEFINE_xxx multilib vars will go with them

ive done this now
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]