On Sat, Sep 12, 2015 at 6:00 AM, Duncan <1i5t5.dun...@cox.net> wrote:
>
> Just bite the bullet and create entire USE flag families such that an
> ebuild can choose the flag appropriate to how it actually uses it.  AFAIK
> this would need EAPI help, for reasons given below, but it should be
> doable.
>
> gui
> gui-gtk
> gui-gtk-2
> gui-gtk-3
> gui-qt
> gui-qt-4
> gui-qt-5

I'm going to have to read the rest of your email about 14 times to
fully grok it, but one thing that strikes me about this approach, and
perhaps mine as well, is that this assumes that USE=-gui should imply
USE="-gtk -qt" or similar.

What if qt or gtk is used for more than just the GUI.  What if the
console version of the program still uses other functions in these
toolkits besides window decoration/etc?

Granted, I suspect that in such a case turning off any of this stuff
is probably not build-time-configurable.  If you want the console-only
version you'd just pass the appropriate command line option (like
deluge's --ui option).

However, it is conceivable that you could design a build system so
that the GUI requires qt and libfoo, spell check requires qt only, and
you could build the program with GUI support, spell check support, or
neither.  If you built with USE="-gui spellcheck" then you'd want qt
enabled but libfoo disabled.  That is obviously a highly contrived
example and perhaps we don't need to worry about this scenario.
However, it does illustrate the general danger of making USE flags a
strict hierarchy.  A hierarchy like qt/qt4 is probably fairly safe,
but when you generalize to gui/qt/qt4 you're making the assumption
that qt is only used for guis.

But I do like the concept, well, conceptually.

-- 
Rich

Reply via email to