Re: [gentoo-dev] splitting build deps out from depends

["Brian D. Harring" <ferringb@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2940 bytes --]

Clarification, mixture of the emails I haven't responded to addressed 
here (further, sorry for the delay, didn't think the thread would go 
any further while I was offline for birthdays/4th of july stuff)...

On Wed, Jul 06, 2005 at 04:39:14AM +0200, Martin Schlemmer wrote:
> On Tue, 2005-07-05 at 20:59 -0500, Brian Jackson wrote:
> > Martin Schlemmer wrote:
> > <snip>
> > >>
> > >>Big picture here:
> > >>* BDEPEND does nothing now, so don't worry about it if you don't want to
> > >>* in the future it will make other things possible
> > >>* give the man problems you see with the proposal, not just tell him that 
> > >>portage doesn't handle it right now... I think out of anyone, he knows what 
> > >>portage does and doesn't handle
> > >>
> > > 
> > > 
> > > I did ask Brian in another reply how he thought to implement it.
> > > 
> > > This one however I read as Drake saying/asking that we should start
> > > doing it now, and I tried to explain why we could not up until now, and
> > > still cannot.   Correct me if I interpreted it wrongly.
> > > 
> > > 
> > 
> > I don't know why we can't start now if we want. BDEPEND will be silently
> > ignored, so current versions of portage will just be blissfully ignorant.
> > 
> > Am I missing something?
> > 
> 
> Yeah, I thought Drake was talking about DEPEND (that was at least what
> he said), not BDEPEND.
Adding it into DEPEND now would cause holy hell, definitely not 
advocating that approach, it's not backwards compatible and it's 
jumping the gun with no gain aside from breaking the tree since the 
current resolver likes to go loco.

Restating, the actual chost atoms *must* be seperated from ctarget 
deps.  It allows current portage to pretty much ignore them (thus not 
taxing the current resolver), and it provides portage with 
classification of those deps.

> 
> > Some of us think we can't start now, others think we can. I was under the
> > impression from ferringb that we could.
> > 
> 
> BDEPEND should be fine to start now depending on faith.
Not after having it rolled into the tree, _yet_.  First email pretty 
much stated I was just after seeing if it was tenuable beyond just the 
portage crews views on it :)

Basically, I was attempting to get feedback on issues where this 
wouldn't be quiet enough, an example of which is ncurses.
(my understanding of this, thanks to flameeyes for clueing me in)
ncurses built/installed in chost==ctarget, BDEPEND=
ncurses built/installed in chost!=ctarget, BDEPEND=ncurses

So... need to expose either ctarget as some type of flag for bdepend, 
or use flag type hack (native when chost=ctarget, -native when 
evaluating a use conditional in a domain where chost!=ctarget).

Thoughts regarding it?  I'd expect we'll have to expose ctarget info 
in some way for use conditionals, but would like some feedback on what 
else may be required.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]