1 |
On Thursday 19 July 2001 00:08, you wrote: |
2 |
> Hi Dan.... |
3 |
> |
4 |
> A couple thoughts.... |
5 |
> |
6 |
> It seems to me that this system is too centralised. Someone is going to |
7 |
> have to maintain all the WITH variables in CVS and this also creates a |
8 |
> possibility of changes to that file impacting many ebuilds. Also, there is |
9 |
> a certain amount of duplication in intent between WITH variables and USE |
10 |
> variables, as shown in your example with QT. QT seems to be both a USE |
11 |
> variable and a WITH variable defined in two separate files. |
12 |
|
13 |
No, No! This is a proprosition to *replace* USE flags. Thre will be *only* |
14 |
With flags. |
15 |
|
16 |
Also, once it's set up, it shouldn't be difficult to maintain/update. If I |
17 |
write a new ebuild and I want to ask the user a question, I only need |
18 |
result=Which(a,b,c,"explanation") or result=With(x=yes,"explanation"). |
19 |
If I want to decide whether to use a recognized With flag, I only need to ask |
20 |
a question about it. |
21 |
|
22 |
If I want to add a flag to make.*, it gives 2 benefits: |
23 |
1. The user can customize it in make.conf. |
24 |
2. It can be part of a group, which can give the user more info and a better |
25 |
default choice in a Which selection. |
26 |
|
27 |
And all it takes is a line in make.defaults and optionally another in |
28 |
make.conf, with some comments for user customization. |
29 |
|
30 |
Even the proposed "group managing" isn't very complex IMHO. |
31 |
|
32 |
But many flags will be particular to one ebuild and won't be added to make.*, |
33 |
so it's easy enough. |
34 |
|
35 |
> |
36 |
> Why not keep WITH variables local to the ebuild file itself? I think this |
37 |
> would have several advantages despite putting a certain amount of work back |
38 |
> onto the ebuilder. I think it would be easier to implement and manage. |
39 |
> Ebuild wouldn't need to be changed as much; it would only involve adding an |
40 |
> interact() function that asked the questions and then set the variables to |
41 |
> be used downstream. This would even reduce the work in upgrading existing |
42 |
> ebuilds if WITH variables can just update (locally) the value of a USE |
43 |
> variable. There doesn't seem to be much benefit to having a central list of |
44 |
> these WITH variables and in somes ways they seem to overlap the purpose of |
45 |
> USE variables. |
46 |
|
47 |
That's just what I mean. With variables will replace USE variables, and some |
48 |
of them will be local to the ebuild file. |
49 |
|
50 |
> |
51 |
> I think the biggest use of these would be to (a) override a USE variable |
52 |
> (b) specify which of several conflicting USE variables to use, and (c) to |
53 |
> provide one-off configuration options. |
54 |
> |
55 |
> I do like the idea of presenting a list of mutually exclusive options along |
56 |
> with a blurb about how to use them. There are lots of cases where you need |
57 |
> to choose which library or option you want and your choices may not be |
58 |
> consistent across packages. The idea of defining such a list as a group and |
59 |
> then specifying that group as the USE works well too. |
60 |
> |
61 |
> Basically I think that WITH variables should be locally defined or |
62 |
> overridden USE variables, and treated just like USE variables once inside |
63 |
> the current standard ebuild functions. All we would need is another |
64 |
> function that can be triggered (interactive()?) to go through the list of |
65 |
> WITH variables, define them according to the user's preferences, and set |
66 |
> them as USE variables. The definition system you propose is fine and those |
67 |
> definitions would just be stored in a section of the ebuild. |
68 |
> |
69 |
> Cheers, |
70 |
> |
71 |
> Sean |
72 |
> |
73 |
> ------------------------------------------------------------------------ |
74 |
> Sean Mitchell Software Engineer |
75 |
> smitchell@×××××××××××××××××××.com Phoenix Interactive Design Inc |
76 |
> tel. 519-679-2913 x237 4th Floor, 137 Dundas St |
77 |
> fax. 519 679 6773 London, ON, Canada N6A 1E9 |
78 |
> ICQ# 104246806 |
79 |
> ------------------------------------------------------------------------ |
80 |
> |
81 |
> > -----Original Message----- |
82 |
> > From: Dan Armak [mailto:danarmak@g.o] |
83 |
> > Sent: Wednesday, July 18, 2001 4:13 PM |
84 |
> > To: gentoo-dev@××××××××××.org |
85 |
> > Subject: [gentoo-dev] New system to replace USE flags |
86 |
> > |
87 |
> > |
88 |
> > Hi all, |
89 |
> > |
90 |
> > This is a followup to the discussion on the thread |
91 |
> > "Suggestion: DONT_USE |
92 |
> > flags". It describes a new (suggested) system to replace USE |
93 |
> > flags. I don't |
94 |
> > include the reasons for switching, they should be obvious. |
95 |
> > |
96 |
> > This is a very long post. It includes not just ideas but |
97 |
> > syntax examples etc. |
98 |
> > This are just examples, sometimes not even suggestions. If |
99 |
> > even half of what |
100 |
> > I've written here is implemented, it will be complete success |
101 |
> > for this memo. |
102 |
> > |
103 |
> > Comments are gladly accepted, only please try to read |
104 |
> > everything first. |
105 |
> > |
106 |
> > ------- |
107 |
> > |
108 |
> > For clarity, let's call the new system With flags. |
109 |
> > |
110 |
> > With flags can serve different purposes: |
111 |
> > 1. They can set usage of shared libraries e.g. qt, sdl. |
112 |
> > 2. They can set ebuild-specific options and program-specific |
113 |
> > configuration |
114 |
> > details. This doesn't mean duplicating the program's |
115 |
> > configuration files, but |
116 |
> > rather more global things. |
117 |
> > 3. They can address h/w availability & utils (e.g. mmx, |
118 |
> > 3dnow, pcmcia) and |
119 |
> > other misc. things. |
120 |
> > This isn't an important distinction, the above 3 things are |
121 |
> > just examples. |
122 |
> > |
123 |
> > In make.globals (or somewhere else), a large number of With |
124 |
> > flags will be |
125 |
> > defined. They will all have default values (yes/no), either static or |
126 |
> > dynamically determined based on the values of other With flags. |
127 |
> > |
128 |
> > Note: I may be misunderstaing the use of make.globals. What I |
129 |
> > need is a file |
130 |
> > with unchanging factory settings, which can be customized in |
131 |
> > make.conf. |
132 |
> > |
133 |
> > An entry will look like this (2 lines): |
134 |
> > |
135 |
> > qt=yes |
136 |
> > an X interface library, used e.g. by KDE. |
137 |
> > |
138 |
> > Every With flag can have 2 parts of increasing verbosity: |
139 |
> > 1. Name. ex: qt. Default value appended. |
140 |
> > 2. Description. ex: an X interface library, used e.g. by KDE. |
141 |
> > |
142 |
> > The above gives an example of a static definition of a flag's |
143 |
> > default value. |
144 |
> > A dynamic definition would look like this: |
145 |
> > |
146 |
> > flagA=yes |
147 |
> > flagB=no |
148 |
> > flagC=flagA # gives yes |
149 |
> > flagD=!flagA # ! is not, gives no |
150 |
> > flagE=flagA|flagB # | is inclusive or, gives yes |
151 |
> > |
152 |
> > and so on. |
153 |
> > |
154 |
> > In make.conf there will be a partial list of flags, |
155 |
> > preferrably with short |
156 |
> > comments, for user setting. A user can thus override any |
157 |
> > default setting. He |
158 |
> > can also add to make.conf any flag from make.globals and set |
159 |
> > it, even if it |
160 |
> > isn't in make.conf's default list. |
161 |
> > |
162 |
> > An example entry in make.conf: |
163 |
> > |
164 |
> > qt=yes # override here |
165 |
> > an X interface library, used e.g. by KDE. # This is a description |
166 |
> > |
167 |
> > The make.conf entry's description might be longer than the |
168 |
> > make.globals one. |
169 |
> > |
170 |
> > The default list should only include things which apply to |
171 |
> > more than just one |
172 |
> > or two packages, and which can be understood by the average end |
173 |
> > user/developer who isn't particularly familiar with the |
174 |
> > library/package |
175 |
> > discussed. No ebuild-specific (e.g. configuration) settings |
176 |
> > should go here. |
177 |
> > |
178 |
> > The default way of will be non-interactive, essentially the |
179 |
> > same as it is |
180 |
> > now. However, emerge (and ebuild) will accept a --interactive |
181 |
> > parameter. |
182 |
> > |
183 |
> > Whenever an ebuild needs to make any decision, it will call a |
184 |
> > function |
185 |
> > provided by emerge (or ebuild). So (I know this isn't a shell |
186 |
> > script, but I |
187 |
> > hate shell scripts!): |
188 |
> > |
189 |
> > # need to know whether to build qt interface |
190 |
> > result = with(qt, "foo uses qt to such and such an effect.") |
191 |
> > |
192 |
> > The second parameter to the with function is the description of the |
193 |
> > applicability of the With flag to this specific ebuild, and |
194 |
> > what the ebuild |
195 |
> > will do without it. |
196 |
> > The ebuild will get a response, it doesn't need to know how |
197 |
> > the decision was |
198 |
> > made. |
199 |
> > |
200 |
> > The function will have two modes: interactive and noninteractive. |
201 |
> > |
202 |
> > In noninteractive mode (the default), the With answer will be |
203 |
> > decided based |
204 |
> > on the default value (from make.globals) and the user-defined |
205 |
> > value if |
206 |
> > present (make.conf). |
207 |
> > |
208 |
> > In interactive mode, activated by the --interactive command |
209 |
> > line parameter, |
210 |
> > the user will be asked to decide. This is where the |
211 |
> > description of the flag |
212 |
> > is used. |
213 |
> > The user will see: |
214 |
> > |
215 |
> > # emerge --interactive foo.ebuild |
216 |
> > Calculating dependencies.. done! |
217 |
> > |
218 |
> > >>> emerge foo to / |
219 |
> > |
220 |
> > Decide: qt (default yes, override No): |
221 |
> > Description: an X interface library, used e.g. by KDE |
222 |
> > Specifics: foo uses qt to such and such an effect. |
223 |
> > [y/N] |
224 |
> > |
225 |
> > Note: not all flags need to be defined somewhere! If an |
226 |
> > ebuild calls with on |
227 |
> > an undefined flag, it needs to supply a default value. This |
228 |
> > is the value |
229 |
> > returned to it in noninteractive mode. The call would become: |
230 |
> > |
231 |
> > result = with(qt=yes, "foo uses qt to such and such an effect.") |
232 |
> > |
233 |
> > Dynamic definitions can be used as well as static, as defined earlier. |
234 |
> > |
235 |
> > The next thing to have is choice betwen mutually exclusive |
236 |
> > With flags (this |
237 |
> > is sorely lacking in the USE system). |
238 |
> > |
239 |
> > An ebuild might look so: |
240 |
> > # Choose between mutually exclusive sound output interfaces |
241 |
> > result=which(sdl_mixer, libmikmod, "Any one of these will do |
242 |
> > for sound.") |
243 |
> > |
244 |
> > In interactive mode, the user will see: |
245 |
> > |
246 |
> > # emerge --interactive foo.ebuild |
247 |
> > Calculating dependencies.. done! |
248 |
> > |
249 |
> > >>> emerge foo to / |
250 |
> > |
251 |
> > Choose: sdl_mixer, libmikmod (default sdl_mixer): |
252 |
> > Specifics: Any one of these will do for sound. |
253 |
> > [sdl_mixer/libmikmod] |
254 |
> > |
255 |
> > sdl_mixer is default, simply because it is named first. That |
256 |
> > is, the ebuild |
257 |
> > should pass the name of what it wants as default first. |
258 |
> > Of course this will accept more than two flags at a time. |
259 |
> > There is no Description (only Specifics) because this is not |
260 |
> > a 'generic' |
261 |
> > situation. An ebuild can request choice between any |
262 |
> > combination of flags in |
263 |
> > any order. |
264 |
> > The last parameter passed to Which is thus the Specifics |
265 |
> > string, all the |
266 |
> > others are taken to be names of With flags. |
267 |
> > |
268 |
> > In non-interactive mode, the which function will simply |
269 |
> > return the first flag |
270 |
> > named, sdl_mixer in this example. |
271 |
> > |
272 |
> > As above, a flag undefined in make.globals and make.conf can |
273 |
> > be used. No |
274 |
> > default value for it is needed. You can just pass a list of flags. |
275 |
> > |
276 |
> > ------- |
277 |
> > |
278 |
> > Subsystem: default values of mutually exclusive choices - groups: |
279 |
> > |
280 |
> > It is true that an ebuild can pass any list of flags and get |
281 |
> > a result. |
282 |
> > However, for noninteractive operation, it would be very |
283 |
> > useful to assign |
284 |
> > default results outside the ebuild (i.e. not by selecting the |
285 |
> > order of flags |
286 |
> > passed to which). |
287 |
> > For this purpose, flags can be 'registered' in make.globals |
288 |
> > (or make.conf) as |
289 |
> > belonging to a group (or several groups). An example make.* entry: |
290 |
> > |
291 |
> > sdl_mixer=yes (audio-out) |
292 |
> > Description of sdl_mixer. |
293 |
> > |
294 |
> > libmikmod=yes (audio-out) |
295 |
> > Description of libmikmod. |
296 |
> > |
297 |
> > The entries thus classified will be arranged by group. The |
298 |
> > first flag in a |
299 |
> > group to be listed becomes the default choice for that group. |
300 |
> > |
301 |
> > A flag can be part of any number of groups, or none. Example: |
302 |
> > libggi=!libsdl (audio-out,video-out) |
303 |
> > |
304 |
> > Whenever an ebuild calls which on flags that are all part of |
305 |
> > one group (e.g. |
306 |
> > audio-out), this becomes the default for an interactive |
307 |
> > choice, and the |
308 |
> > result returned from a noninteractive one. |
309 |
> > |
310 |
> > The ebuild doesn't need to know the name of the group, or |
311 |
> > even that there is |
312 |
> > one. |
313 |
> > |
314 |
> > And, if even this isn't enough, we could add a Groups section |
315 |
> > in make.* which |
316 |
> > would: |
317 |
> > 1. Optionally define a group as a list of flags, even if |
318 |
> > those flags don't |
319 |
> > specify themselves as part of the group. |
320 |
> > 2. Define the group's order. |
321 |
> > 3. Provide an extra description of the group. |
322 |
> > For example: |
323 |
> > |
324 |
> > <groups> |
325 |
> > audio-out=libmikmod,sdl_mixer,libggi |
326 |
> > The audio-out group is foobar foobar foo. |
327 |
> > |
328 |
> > In this example, the order in whch the flags are defined is |
329 |
> > overriden, and |
330 |
> > libmikmod is set to be the new default choice. |
331 |
> > |
332 |
> > The reason we have an entire list and not just a default |
333 |
> > value is subgroups. |
334 |
> > If an ebuild asks |
335 |
> > result=which(sdl_mixer,mikmod,libggi,"select audio lib") |
336 |
> > then it will get libmikmod (from noninteractive mode) since |
337 |
> > it's first in the |
338 |
> > list defined in make.*'s <groups>. |
339 |
> > If however it says result=which(libggi,libmikmod,"subgroup |
340 |
> > choice") then it |
341 |
> > will get sdl_mixer because that's the best ('foremost') |
342 |
> > choice left without |
343 |
> > sdl_mixer. |
344 |
> > |
345 |
> > ------- |
346 |
> > |
347 |
> > Comments welcome! |
348 |
> > |
349 |
> > -- |
350 |
> > |
351 |
> > Dan Armak |
352 |
> > Gentoo Linux Developer |
353 |
> > Matan, Israel |
354 |
> > |
355 |
> > _______________________________________________ |
356 |
> > gentoo-dev mailing list |
357 |
> > gentoo-dev@××××××××××.org |
358 |
> > http://cvs.gentoo.org/mailman/listinfo/gentoo-dev |
359 |
> |
360 |
> _______________________________________________ |
361 |
> gentoo-dev mailing list |
362 |
> gentoo-dev@××××××××××.org |
363 |
> http://cvs.gentoo.org/mailman/listinfo/gentoo-dev |