[Exherbo-dev] Multilib branch now merged

Bo Ørsted Andresen zlin at exherbo.org
Sat Jan 7 22:44:19 GMT 2012


On Fri, Dec 30, 2011 at 09:03:03PM +0000, David Leverton wrote:
> The multibuild_c: options should really be declared in an exlib,
> including a restriction to make sure at least one is selected (or for
> C at least, should we always force the native ABI on in the profile?)

I suppose an exlib could use something like:

myexparam multibuild_options="multibuild_c: 32 64"
MYOPTIONS="( $(exparam multibuild_options) )"

The reason we haven't done it before is because adding options in an
exlib can't be overridden in special cases. I.e. without an exparam.

And also adding the options to MYOPTIONS wasn't any harder than
requiring an extra exlib. I suppose that changes if it starts adding
restrictions to the options.

I think the native C ABI does need to be forced on in the profiles.
Python or Ruby ABIs don't though since there really isn't a native ABI
for those.

> Maybe easy-multibuild should have a `multiunpack` exparam or something
> to make it easier to handle packages that don't support out-of-tree
> builds.

We originally decided against this because we really wanted people to
add support for out-of-tree builds instead by discouraging multiunpack.

I don't have a strong opinion about it though.

> I think I'd prefer for -m32 to be put in CC rather than CFLAGS (maybe
> because it looks funny for scripts to say "checking for
> i686-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc", also the way it is
> now requires it to be in LDFLAGS as well), but it would have to be
> done in a way that doesn't interfere with users specifying their own
> CC.
> 
>  - Not multibuild-related specifically, but we should maybe check
> whether all the random FOO=${CHOST}-foo variables we set in the
> profiles are appropriate.  In particular some packages apparently want
> ${LD} to be the C compiler, not ld itself.

If we don't set LD in the profiles because of this, it means users also
can't sensibly specify LD on their own. Packages handle it
inconsistently. By setting it we hit those kinds of issues consistently
and override it (usually with LD="${CC}") where needed.

Respecting user specified CC and LD is also why unsetting LD like some
exheres do is bad.

> The (?) used for multibuild option dependencies is questionable - if
> the dependency doesn't have the multibuild options then presumably it
> isn't multibuildified and therefore shouldn't be considered, surely?
> (-) seems like it would be better.

We originally wanted to test having Paludis add those (?) dependencies
to everything automagically. With (?) it would apply only to packages
that have multibuild options.

If we're never going to do that it makes sense to convert to (-) though.
But some of the current (?) dependencies really haven't been
multibuildified nor should they be, so whoever converts it would need to
fix those properly.

--
Bo Ørsted Andresen



More information about the Exherbo-dev mailing list