[gentoo-embedded] splitting build deps out from depends

[Brian D. Harring]

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