Thanks for picking this up again :) We need to handle dependencies properly to not regress on multibuild. I don't want to resolve the dependencies for e.g. wine manually to compile wine32 and I assume no-one else wants to do that either. So we need paludis to resolve dependencies within the target arch and cross compile things as needed. We also need additional syntax, at least for build-time dependencies, as those can be needed for either one of the arches.
In my opinion, this is critical before we can think about merging cross. Another, less critical problem are alternatives. If you install e.g. mawk on your host-arch and select it as your awk provider, then your cross-arch suddenly has no awk anymore. To fix that we would need to make eclectic aware of the target, but for now we could just mandate that you install the same providers for both arches. Cheers Benedikt On Sat, Feb 28, 2015 at 7:22 PM, Saleem Abdulrasool <[email protected]> wrote: > Hello exherbo-dev, > > I think that its about time that we consider crossing over to cross. For > most people, this is a one-time hassle of migrating the system layout. The > file system layout change is the piece that will enable supporting cross. > However, it brings us a much nicer multi-arch configuration, and a much > nicer mechanism for supporting multiple ABIs (which multi build originally > set out to solve). See [1] for additional details on the layout and > reasoning. > > Once the layout changes are done, we can make further incremental > improvements to cross to make it easier and nicer to use. We have > previously taken a similar approach with multibuild, and it worked out well, > and I would like to do something similar here. > > In preparation for this migration, I would like to gather the set of things > that we must do before we actually engage in merging the necessary changes. > gcc:4.9 was fixed up on cross recently, and should be usable for at least > the common case of a single host system. One known limitation is the split > debug (which I think can be addressed before the merge). AFAICT, system > should more or less work (though, due to the migration case, requires > acrobatics with options to break circular dependencies). > > The conversion is slightly painful, but certainly possible. It involves > acrobatics similar to bootstrapping exherbo on another linux distribution. > Starting from a stage would be the simpler approach. We can still document > both options and let the brave hearted try the more difficult option. > > [1] http://exherbo.org/docs/multiarch.txt > > -- > Saleem Abdulrasool > compnerd (at) compnerd (dot) org > > _______________________________________________ > 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
