| 1 |
Raymond Jennings posted on Fri, 11 Sep 2015 21:55:46 -0700 as excerpted: |
| 2 |
|
| 3 |
> On Fri, Sep 11, 2015 at 5:13 AM, Rich Freeman <rich0@g.o> wrote: |
| 4 |
> |
| 5 |
>> USE=gui or something like that if the main effect is to have a gui or |
| 6 |
>> not. That is the sort of thing that SHOULD go in make.conf or in a |
| 7 |
>> profile. If disabling gtk makes it a console-only application then use |
| 8 |
>> the gui flag. |
| 9 |
>> |
| 10 |
>> USE=gtk if the main effect is to select /which/ toolkit is used if more |
| 11 |
>> than one is optionally supported. That /might/ go in a make.conf or |
| 12 |
>> profile, but probably shouldn't in general. It is more appropriate for |
| 13 |
>> something like the desktop/gnome profile than the desktop profile. |
| 14 |
>> |
| 15 |
>> USE=gtk# if you're picking which version to use. That should /almost |
| 16 |
>> never/ go in a profile (unless you're talking about a testing profile |
| 17 |
>> of some kind, such as on an overlay), or in a global config unless you |
| 18 |
>> REALLY know what you're getting into. Users setting this globally |
| 19 |
>> should expect to run into bugs. The package should default these flags |
| 20 |
>> to whatever is most appropriate for the specific package. |
| 21 |
>> |
| 22 |
> I really like this approach, and I think that having tiers of |
| 23 |
> (gui)->(qt/gtk)->(qt4/qt5//gtk2/gtk3) would go a long way to keeping USE |
| 24 |
> flags coherent. |
| 25 |
|
| 26 |
|
| 27 |
The other possibility, which I haven't seen raised but if we're going to |
| 28 |
examine the options I think we at least need this on record as having |
| 29 |
been discussed, is... |
| 30 |
|
| 31 |
Just bite the bullet and create entire USE flag families such that an |
| 32 |
ebuild can choose the flag appropriate to how it actually uses it. AFAIK |
| 33 |
this would need EAPI help, for reasons given below, but it should be |
| 34 |
doable. |
| 35 |
|
| 36 |
gui |
| 37 |
gui-gtk |
| 38 |
gui-gtk-2 |
| 39 |
gui-gtk-3 |
| 40 |
gui-qt |
| 41 |
gui-qt-4 |
| 42 |
gui-qt-5 |
| 43 |
|
| 44 |
(Do we want X and wayland variants of the above?) |
| 45 |
|
| 46 |
req-alt-gtk |
| 47 |
req-alt-gtk-2 |
| 48 |
req-alt-gtk-3 |
| 49 |
req-alt-qt |
| 50 |
req-alt-qt-4 |
| 51 |
req-alt-qt-5 |
| 52 |
|
| 53 |
choice-alt-gtk |
| 54 |
choice-alt-gtk-2 |
| 55 |
choice-alt-gtk-3 |
| 56 |
choice-alt-qt |
| 57 |
choice-alt-qt-4 |
| 58 |
choice-alt-qt-5 |
| 59 |
|
| 60 |
... |
| 61 |
|
| 62 |
Then people could set in make.conf something like... |
| 63 |
|
| 64 |
USE="gui -gui-qt-5" |
| 65 |
|
| 66 |
... which would mean "I normally want GUI features built, but not if it |
| 67 |
means pulling in qt5." |
| 68 |
|
| 69 |
For the req-alt (required alternative) flags, the user could set ONLY ONE |
| 70 |
at a specific choice-level (here, the gtk/qt choice level, and the gtk2/3 |
| 71 |
and qt4/5 choice-levels), with EAPI enforcing it. |
| 72 |
|
| 73 |
Then an ebuild would set the /deepest/ level it needed, and possibly a |
| 74 |
choice variable, something like (UH=USE-Hierarchy)... |
| 75 |
|
| 76 |
UH_MAX_LVL="gui-gtk-2,gui-gtk3 level-use-x,level-use-y" |
| 77 |
UH_CHOICE="" |
| 78 |
|
| 79 |
... and the EAPI, possibly plus an eclass to allow expanding the sets, |
| 80 |
would then have logic similar to the following table for the gtk set |
| 81 |
(EAPI support needed as traditional USE flags default off if not set on, |
| 82 |
and three-way flags, on/off/unset, would be necessary here): |
| 83 |
|
| 84 |
! = unset |
| 85 |
- = set -flag |
| 86 |
+ = set flag (+flag) |
| 87 |
x = flag setting doesn't matter |
| 88 |
|
| 89 |
gui gui-gtk gui-gtk-2 gui-gtk-3 note/build |
| 90 |
---------------------------------------------------------------- |
| 91 |
! ! ! ! all unset, build none |
| 92 |
! ! ! - unset/negative, build none |
| 93 |
! ! ! + only gtk3 set, build gtk3 |
| 94 |
! ! - ! unset/negative, build none |
| 95 |
! ! - - unset/negative, build none |
| 96 |
! ! - + build gtk3 |
| 97 |
! ! + ! build gtk2 |
| 98 |
! ! + - build gtk2 |
| 99 |
! ! + + build both gtk2/3 [1] |
| 100 |
|
| 101 |
! - x x -gui-gtk, build none [2] |
| 102 |
|
| 103 |
! + ! ! ebuild-pref [3] |
| 104 |
! + ! - build gtk2 |
| 105 |
! + ! + build gtk3 |
| 106 |
! + - ! build gtk3 |
| 107 |
! + - - build none [4] |
| 108 |
! + - + build gtk3 |
| 109 |
|
| 110 |
- x x x -gui, build none [2] |
| 111 |
|
| 112 |
+ ! ! ! +gui, !others, eb-pref [3] |
| 113 |
|
| 114 |
+ - x x -gui-gtk, build none [5] |
| 115 |
|
| 116 |
+ + ! ! ebuild-pref [3] |
| 117 |
+ + ! - build gtk2 |
| 118 |
+ + ! + build gtk3 |
| 119 |
+ + - ! build gtk3 |
| 120 |
+ + - - build none [4] |
| 121 |
+ + - + build gtk3 |
| 122 |
+ + + ! build gtk2 |
| 123 |
+ + + - build gtk2 |
| 124 |
+ + + + build both gtk2/3 |
| 125 |
-------------------------------------------------------------- |
| 126 |
|
| 127 |
[1] Since UH_CHOICE was unset or null in the ebuild, both can be built. |
| 128 |
If it was set, the user/profile settings for choice-alt-gtk* would be |
| 129 |
evaluated to decide. |
| 130 |
|
| 131 |
[2] With the higher level flag set negative, the lower level flags don't |
| 132 |
matter as the user/profile said they don't want it with the higher level |
| 133 |
flag. |
| 134 |
|
| 135 |
[3] With the higher level set positive and lower levels unset, user/ |
| 136 |
profile doesn't care at the lower level, so build both or maintainer |
| 137 |
pref, if ebuild didn't set UH_CHOICE. If ebuild set UH_CHOICE, only one |
| 138 |
can be built, evaluate the user/profile value for choice-alt-gtk* to |
| 139 |
decide. |
| 140 |
|
| 141 |
[4] User/profile says they want gtk GUI, but don't want either gtk2 or |
| 142 |
gtk3. What? But the effect is gui-gtk but not if it's either of the |
| 143 |
possible gtk options, so don't build them. |
| 144 |
|
| 145 |
[5] User/profile says gui, but not when it's gtk, so gtk builds being the |
| 146 |
only gui possible, don't build them. |
| 147 |
|
| 148 |
|
| 149 |
Obviously if qt4/5 are also options, there'd be a similar matrix for |
| 150 |
them, plus another level controlling the qt/gtk choice. |
| 151 |
|
| 152 |
Fed the correct UH_* settings and deciding based on the user/profile |
| 153 |
settings, the EAPI or eclass function would return a list of options to |
| 154 |
build from among those indicated by the UH_* vars, with the added |
| 155 |
possibility of ebuild-preference, which would let the ebuild choose its |
| 156 |
preferred, or it could build both/all. |
| 157 |
|
| 158 |
At the gtk-only or qt-only levels, there'd be only the version choices. |
| 159 |
Similarly if only one version of each was supported, as it'd then be a qt/ |
| 160 |
gtk choice. But if gtk2/3 and qt4/5 are all supported, there'd have to |
| 161 |
be a way to return "ebuild-choice of gtk, not qt, please", or conversely, |
| 162 |
"ebuild choice of qt, not gtk, please", as well as "ebuild-choice of |
| 163 |
whatever". To complete the set, "ebuild choice of gtk/qt, but if it's |
| 164 |
gtk, I want this version" (and similar for qt) might be worthwhile, but |
| 165 |
I'm not sure whether there'd be a real use-case for that or not. If not, |
| 166 |
perhaps it could simply spit an error, to avoid having to implement that |
| 167 |
bit of the choice matrix. |
| 168 |
|
| 169 |
|
| 170 |
Clearly this would be rather complex to setup, but the idea would be to |
| 171 |
code it once in the EAPI possibly plus the eclass, after which ebuilds |
| 172 |
would simply set the vars according to what choices they had, call the |
| 173 |
function to return the build choice, and let the return tell them what to |
| 174 |
build. Thus, it would be once per PM, plus possibly the expansion in the |
| 175 |
eclass, with little code in the ebuilds themselves. So complex, yes, but |
| 176 |
if it can solve the problem so we don't keep coming back to it... |
| 177 |
|
| 178 |
Like I said, I'm not sure it's practical, but even if not, I believe |
| 179 |
there's value in simply having it on the table for discussion, if for |
| 180 |
nothing else than for actually going there, as an example of the |
| 181 |
potential complexity of trying to take it too far. |
| 182 |
|
| 183 |
-- |
| 184 |
Duncan - List replies preferred. No HTML msgs. |
| 185 |
"Every nonfree program has a lord, a master -- |
| 186 |
and if you use the program, he is your master." Richard Stallman |
Archives