The thought that crossed my mind in big letters was: THANKS On Fri, Dec 30, 2011 at 22:03, David Leverton <[email protected]> wrote: > On 30 December 2011 20:35, David Leverton <[email protected]> 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 > [email protected] > http://lists.exherbo.org/mailman/listinfo/exherbo-dev
_______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
