On Sat, 20 Sep 2008 22:05:43 +0300
Petteri Räty <[EMAIL PROTECTED]> wrote:

> Alexis Ballier kirjoitti:
> > Hi,
> > 
> >> When EAPI 2 goes live built_with_use should probably die for most
> >> cases. 
> > 
> > I don't understand here: you mean die like being removed or die like
> > the die call in an ebuild? If I understood correctly the following
> > it should be the latter.
> > 
> 
> Well we could go with either but if there are valid use cases we need
> to go with the latter.
> 
> >> Are there valid use cases for built_with_use that are not
> >> covered by the use deps in EAPI 2?
> > 
> > I can think of checks like:
> > - foo is a dep/rdep of bar
> > - foo has a "plugin like" architecture
> > - bar will "work" with minimal foo
> > - most people will expect some features in bar that come with foo's
> > plugins
> > - we might want to display warnings for the most useful features
> > - having useflags in bar for each of foo's useflags doesn't seem
> > wise
> > 
> > 
> > Ok that's not really a nice example but I can't think of anything
> > better at the moment.
> > 
> > By the way, how will the --missing option of built_with_use be
> > handled by eapi 2?
> > 
> > Alexis.
> 
> Why should it be any different than what it is now?

i still don't get what you're saying.  using built_with_use should die
as in cause the ebuild to exit with an error code?  or that we should
stop using it for checking use flags?

there are plenty of reasons for using built_with_use that have nothing
to do with dependencies.  i use it in the wxwidgets eclass to determine
what possible configuration tuple(s) the user can have installed.
toolchain.eclass uses it for some cross-compile logic.  in many cases
it's simply used to display elog messages conditionally.

so, please don't make it "die" or i will be ":("


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

Attachment: signature.asc
Description: PGP signature

Reply via email to