On Sat, 8 Feb 2014 13:54:09 -0800 Saleem Abdulrasool <[email protected]> wrote: [...] > - build/host/target flags/tools > > > > Currently there is no way to determine the correct settings for > > tools and flags for the build or target architectures. As a > > workaround, several packages assume build and target tools have a > > prefix of ${arch}-. Additionally, we don't get the variable > > inheritance that ebuild.bash provides for the host system (CFLAGS > > being prepended to CPPFLAGS). As far as how cross-compiling is > > currently set up in paludis, I'm not sure how to solve this issue, > > because tool_prefix is set in the installed repository config (and > > the build/target system installed repository is not involved in the > > installation to a host installed repository). > > I agree that the assumption that ${arch}- is the tool prefix is > incorrect. That is something that exheres should be able to query > from paludis. However, that is something that we can do once we are > certain that we have the desired infrastructure. > > The CFLAGS handling is an ugly wart in the system that is the > artifact of how the prototype was built. I based the build > infrastructure heavily based upon the excellent work that zlin and > company did when I initially brought up multibuild (multilib) on > exherbo. cross does not follow the same build mentality, but rather > relies on paludis targets for targeting each host. This is obviously > something that needs to be revisited. One thought that comes to mind > is to use a target hierarchy for environments, and introduce the > concept of a default target. You could imagine something like: > > /etc/paludis/armv7-unknown-linux-gnueabihf/bashrc > /etc/paludis/i686-pc-linux-gnu/bashrc > /etc/paludis/x86_64-pc-linux-gnu/bashrc > /etc/paludis/default -> /etc/paludis/i686-pc-linux-gnu
bashrc configuration aside, I think we need to support separate profiles per destination. And with that in place we should be able to abandon the CROSS_* handling that's currently hard-coded into ebuild.bash on the wip/cross-compiling paludis branch. [...] > > I know that the cross-compiling branch is still a WIP, but I wonder > > what the plan is for this. It is quite inconvenient to have to > > manage a bunch of configs/environments in order to cross-compile > > for multiple hosts. > > I have no intentions of merging this into master until cross is deemed > ready to merge into master. The work that is on the WIP branch is > specific to cross. The parts work that I did to enable some of this > is now merged to master. Unless there is some other functionality > that is enabled by the current work on the WIP branch, I would rather > leave it there. This is primarily driven by the motivation to not > unnecessarily cause churn on master until we are sure that we are > happy with the infrastructure for cross. We really do need to support more than one cross destination in the same paludis environment... > > Also, dependency resolution for multiarch packages doesn't take into > > account the architecture of installed packages. This makes users > > have to do most dependency resolution for cross-compiled packages > > by hand at the moment. > > > > I see a brief mention of some necessary dependency syntax changes > > in the TODO section of the multiarch migration guide, but I don't > > quite understand the proposal. Maybe someone can expand upon this? > > > There was no concrete proposal that I put forth for this, only vague > mutterings that I think are some things that we should consider to > improve the infrastructure for cross. If there is a particular point > that is unclear to you, I can try to expound on that. I think we probably need one or more additional DEPENDENCY labels. First we need to analyse how many different relations exist between a cross compiled package and its dependencies on the cross platform and the host platform. Then hopefully we can map each of those kinds of relations to one or more labels. -- Bo Ørsted Andresen _______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
