[Exherbo-dev] Multilib branch now merged

Xavier Barrachina xabarci at doctor.upv.es
Sat Dec 31 10:06:40 GMT 2011

The thought that crossed my mind in big letters was:

On Fri, Dec 30, 2011 at 22:03, David Leverton <dleverton at exherbo.org> wrote:
> On 30 December 2011 20:35, David Leverton <dleverton at exherbo.org> wrote:
>> Finally, thanks to everyone who's worked on multilib so far, and to
>> everyone who will take this opportunity to start working on it and
>> make it even better.
> For anyone who wants to work on stuff but isn't sure what to do,
> here's a list of potential improvements that I noticed while working
> on the merge.  These are just my opinions, not anything authoritative,
> and some of them are a too vague to do anything about immediately, but
> I thought it would be good to get them out there and see what people
> think:
> I'm not sure it's appropriate for it to be so generic across classes -
> we'll have to see once someone does Python/Ruby/etc.  For one thing
> this makes it harder to find a suitable place to solve the next point.
> 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?)
> 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.
> lib* should only apply to actual object code libraries or other stuff
> that's different between targets - other files that happen to be
> installed in lib should stay there.
> For amd64 we should probably move to having lib be for 32-bit
> libraries and non-target-specific things (that for whatever reason
> aren't in share) and lib64 as a separate directory (ie no symlinks
> either way) for just the 64-bit libraries.  It's ugly, but it seems to
> be the standard used by other distros so it makes sense to follow it.
> The /usr/${CHOST} scheme assumes that ${CHOST} is different for all
> targets, which isn't true on MIPS for example.  I'm also not sure how
> standard this approach is - at least some configure scripts seem to
> look for ${CHOST}-*-config which suggests that that would be
> preferred, although it has the same problem.  Finally I don't like how
> the default and non-default targets are treated differently, would be
> better to handle them all the same and just symlink the default ones
> to the "bare" names.  Whatever we end up doing should probably be put
> in an exlib.
> 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.
> 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.
> _______________________________________________
> Exherbo-dev mailing list
> Exherbo-dev at lists.exherbo.org
> http://lists.exherbo.org/mailman/listinfo/exherbo-dev

More information about the Exherbo-dev mailing list