1 |
On Sat, Sep 12, 2015 at 6:00 AM, Duncan <1i5t5.duncan@×××.net> wrote: |
2 |
> |
3 |
> Just bite the bullet and create entire USE flag families such that an |
4 |
> ebuild can choose the flag appropriate to how it actually uses it. AFAIK |
5 |
> this would need EAPI help, for reasons given below, but it should be |
6 |
> doable. |
7 |
> |
8 |
> gui |
9 |
> gui-gtk |
10 |
> gui-gtk-2 |
11 |
> gui-gtk-3 |
12 |
> gui-qt |
13 |
> gui-qt-4 |
14 |
> gui-qt-5 |
15 |
|
16 |
I'm going to have to read the rest of your email about 14 times to |
17 |
fully grok it, but one thing that strikes me about this approach, and |
18 |
perhaps mine as well, is that this assumes that USE=-gui should imply |
19 |
USE="-gtk -qt" or similar. |
20 |
|
21 |
What if qt or gtk is used for more than just the GUI. What if the |
22 |
console version of the program still uses other functions in these |
23 |
toolkits besides window decoration/etc? |
24 |
|
25 |
Granted, I suspect that in such a case turning off any of this stuff |
26 |
is probably not build-time-configurable. If you want the console-only |
27 |
version you'd just pass the appropriate command line option (like |
28 |
deluge's --ui option). |
29 |
|
30 |
However, it is conceivable that you could design a build system so |
31 |
that the GUI requires qt and libfoo, spell check requires qt only, and |
32 |
you could build the program with GUI support, spell check support, or |
33 |
neither. If you built with USE="-gui spellcheck" then you'd want qt |
34 |
enabled but libfoo disabled. That is obviously a highly contrived |
35 |
example and perhaps we don't need to worry about this scenario. |
36 |
However, it does illustrate the general danger of making USE flags a |
37 |
strict hierarchy. A hierarchy like qt/qt4 is probably fairly safe, |
38 |
but when you generalize to gui/qt/qt4 you're making the assumption |
39 |
that qt is only used for guis. |
40 |
|
41 |
But I do like the concept, well, conceptually. |
42 |
|
43 |
-- |
44 |
Rich |