Hola. Quick statement of terminology- x-compile == cross compiling, building arm crap on an x86, building up a x-compile target in a subdirectory of / (fex)
Currently, we pretty much leave out the big dogs of build depends from ebuilds- basically we rely on the profile to require a suitable toolchain. Couple of issues with this though- 1) Deps aren't complete for an ebuild. 2) Merging a php or python lib that doesn't require compilation doesn't require a full toolchain, distutils/pear or make mainly. So autoassuming a c/c++ toolchain is required isn't accurate. 3) For automatically handling x-compile deps, without this info bound to an ebuild, portage will _never_ be able to know what dependencies are x-compile targets, and what deps must be natively merged. So... why don't we add a new DEPEND, BDEPEND (build depends), that holds atoms of what is required to actually build the package, literally, what executes on the box to build that package. Still would have DEPEND, since (using diffball as an example) building it doesn't execute anything from bzip2/libz, it just builds against those atoms. Aside from the goal of having complete dependencies, BDEPEND can be used by portage to know what needs to be built native to that box, vs what is an x-compiled dependency. So... we could actually do a full stategraph covering x-compile deps, and the actual x-compile toolchain. Thing is, it's an extra bit ebuild devs have to deal with. So get out your pitchforks/torches and throw in your two cents on the extra bit of effort required from ebuild devs. In the circles where this idea developed in, it solves some nasty portage issues (iow, it's useful to us for addressing a hard problem and supplying further functionality). Re: backwards compatibility, profile's holding the toolchain pretty much covers up the fact BDEPEND is missing from the tree; it's a non issue, only an issue if you're cross compiling (spanky's x-compile work mostly gets around this afaik, although it's something of abuse of portage), or if your profile doesn't specify a full toolchain. In other words, those who fall into the two scenarios above are already dealing with this issue, so there really isn't a concern of backwards compatibility. Either way, kindly chuck in your two cents (preferably on -dev ml, since this is cross posted). ~harring
pgpq2H1iWG2bn.pgp
Description: PGP signature
