On Thu, Aug 12, 2010 at 08:19:48AM -0700, Mandeep Singh Baines wrote: > Zac Medico (zme...@gentoo.org) wrote: > > I was working on writing documentation for the HDEPEND patch when I > > realized that it seems simpler for ebuild developers if we divide the > > dependencies as follows : > > > > Thanks much for adding this support:) This will definitely make life > much easier for folks who need to cross-compile. But I have one > quick question. > > Why would TDEPEND be simpler? I suspect that target build dependencies > (header files and static libraries) are more common than host build > dependencies (build tools). Most packages have no host build dependencies > other than the toolchain which is implicit.
Just a sidenote, but the implicit toolchain some of us have been eyeing to kill for half a decade now- mainly since not having those deps explicit has made it hard to do new profile bring up among other things. Implicit deps pulls info away from the resolver (which originally couldn't handle that info, thus why it was never available) and makes the system pkgset for better or worse the base.
Scenarios where people were trying to use uclibc caused some issues w/ that- I half expect any clang experiments will be similar also.
> So for most packages, > you wouldn't need to do anything to support cross-compiling for the > HDEPEND case. For the TDEPEND case, you'd have to modify a lot of > packages. Especially, considering the fact that DEPEND=RDEPEND is the > common case. > > The other nice property of HDEPEND is that DEPEND and RDEPEND are target > and HDEPEND in host. With TDEPEND, DEPEND would be host while RDEPEND > would be target. So HDEPEND seems more intuitive. But that might be > more intuitive to me cuz I mostly cross-compile. Perhaps not more > intuitive for someone who doesn't.
Offhand, I'd probably favor HDEPEND for this over TDEPEND since I suspect HDEPEND is easier to sell gentoo devs on converting to- at first glance it looks like it's less conversion effort.
That said, there is a lot of automake, cmake, qt-make, etc, style deps that are in the tree so it's not going to be a "snap your fingers and it's done" scenario. I've not done any pquery scans however- would be useful if someone did anyways, since the same list used for that scan should be inclucded in the GLEP- specifically an initial list of "these are very likely host deps vs target deps".
Corner case, but has anyone looked at how things like python extensions would fit in this? I'm specifically thinking of pkgs that use distutils and friends to install (meaning they need a working python) yet compile extensions for the target- roughly it would be HDEPEND and DEPEND on python, but for that class of ebuilds I don't see how it would be handleded cleanly w/in the ebuild itself.