Re: [gentoo-dev] New system to replace USE flags

[Dan Armak <ermak@netvision.net.il>]

On Thursday 19 July 2001 00:08, you wrote:
> Hi Dan....
>
> A couple thoughts....
>
> It seems to me that this system is too centralised. Someone is going to
> have to maintain all the WITH variables in CVS and this also creates a
> possibility of changes to that file impacting many ebuilds. Also, there is
> a certain amount of duplication in intent between WITH variables and USE
> variables, as shown in your example with QT. QT seems to be both a USE
> variable and a WITH variable defined in two separate files.

No, No! This is a proprosition to *replace* USE flags. Thre will be *only* 
With flags.

Also, once it's set up, it shouldn't be difficult to maintain/update. If I 
write a new ebuild and I want to ask the user a question, I only need 
result=Which(a,b,c,"explanation") or result=With(x=yes,"explanation").
If I want to decide whether to use a recognized With flag, I only need to ask 
a question about it.

If I want to add a flag to make.*, it gives 2 benefits:
1. The user can customize it in make.conf.
2. It can be part of a group, which can give the user more info and a better 
default choice in a Which selection.

And all it takes is a line in make.defaults and optionally another in 
make.conf, with some comments for user customization.

Even the proposed "group managing" isn't very complex IMHO.

But many flags will be particular to one ebuild and won't be added to make.*, 
so it's easy enough.

>
> Why not keep WITH variables local to the ebuild file itself? I think this
> would have several advantages despite putting a certain amount of work back
> onto the ebuilder. I think it would be easier to implement and manage.
> Ebuild wouldn't need to be changed as much; it would only involve adding an
> interact() function that asked the questions and then set the variables to
> be used downstream. This would even reduce the work in upgrading existing
> ebuilds if WITH variables can just update (locally) the value of a USE
> variable. There doesn't seem to be much benefit to having a central list of
> these WITH variables and in somes ways they seem to overlap the purpose of
> USE variables.

That's just what I mean. With variables will replace USE variables, and some 
of them will be local to the ebuild file.

>
> I think the biggest use of these would be to (a) override a USE variable
> (b) specify which of several conflicting USE variables to use, and (c) to
> provide one-off configuration options.
>
> I do like the idea of presenting a list of mutually exclusive options along
> with a blurb about how to use them. There are lots of cases where you need
> to choose which library or option you want and your choices may not be
> consistent across packages. The idea of defining such a list as a group and
> then specifying that group as the USE works well too.
>
> Basically I think that WITH variables should be locally defined or
> overridden USE variables, and treated just like USE variables once inside
> the current standard ebuild functions. All we would need is another
> function that can be triggered (interactive()?) to go through the list of
> WITH variables, define them according to the user's preferences, and set
> them as USE variables. The definition system you propose is fine and those
> definitions would just be stored in a section of the ebuild.
>
> Cheers,
>
> Sean
>
> ------------------------------------------------------------------------
>  Sean Mitchell                                        Software Engineer
>  smitchell@phoenix-interactive.com       Phoenix Interactive Design Inc
>  tel. 519-679-2913 x237                        4th Floor, 137 Dundas St
>  fax. 519 679 6773                          London, ON, Canada  N6A 1E9
>                            ICQ# 104246806
> ------------------------------------------------------------------------
>
> > -----Original Message-----
> > From: Dan Armak [mailto:danarmak@gentoo.org]
> > Sent: Wednesday, July 18, 2001 4:13 PM
> > To: gentoo-dev@cvs.gentoo.org
> > Subject: [gentoo-dev] New system to replace USE flags
> >
> >
> > Hi all,
> >
> > This is a followup to the discussion on the thread
> > "Suggestion: DONT_USE
> > flags". It describes a new (suggested) system to replace USE
> > flags. I don't
> > include the reasons for switching, they should be obvious.
> >
> > This is a very long post. It includes not just ideas but
> > syntax examples etc.
> > This are just examples, sometimes not even suggestions. If
> > even half of what
> > I've written here is implemented, it will be complete success
> > for this memo.
> >
> > Comments are gladly accepted, only please try to read
> > everything first.
> >
> > -------
> >
> > For clarity, let's call the new system With flags.
> >
> > With flags can serve different purposes:
> > 1. They can set usage of shared libraries e.g. qt, sdl.
> > 2. They can set ebuild-specific options and program-specific
> > configuration
> > details. This doesn't mean duplicating the program's
> > configuration files, but
> > rather more global things.
> > 3. They can address h/w availability & utils (e.g. mmx,
> > 3dnow, pcmcia) and
> > other misc. things.
> > This isn't an important distinction, the above 3 things are
> > just examples.
> >
> > In make.globals (or somewhere else), a large number of With
> > flags will be
> > defined. They will all have default values (yes/no), either static or
> > dynamically determined based on the values of other With flags.
> >
> > Note: I may be misunderstaing the use of make.globals. What I
> > need is a file
> > with unchanging factory settings, which can be customized in
> > make.conf.
> >
> > An entry will look like this (2 lines):
> >
> > qt=yes
> > an X interface library, used e.g. by KDE.
> >
> > Every With flag can have 2 parts of increasing verbosity:
> > 1. Name. ex: qt. Default value appended.
> > 2. Description. ex: an X interface library, used e.g. by KDE.
> >
> > The above gives an example of a static definition of a flag's
> > default value.
> > A dynamic definition would look like this:
> >
> > flagA=yes
> > flagB=no
> > flagC=flagA		# gives yes
> > flagD=!flagA		# ! is not, gives no
> > flagE=flagA|flagB	# | is inclusive or, gives yes
> >
> > and so on.
> >
> > In make.conf there will be a partial list of flags,
> > preferrably with short
> > comments, for user setting. A user can thus override any
> > default setting. He
> > can also add to make.conf any flag from make.globals and set
> > it, even if it
> > isn't in make.conf's default list.
> >
> > An example entry in make.conf:
> >
> > qt=yes # override here
> > an X interface library, used e.g. by KDE. # This is a description
> >
> > The make.conf entry's description might be longer than the
> > make.globals one.
> >
> > The default list should only include things which apply to
> > more than just one
> > or two packages, and which can be understood by the average end
> > user/developer who isn't particularly familiar with the
> > library/package
> > discussed. No ebuild-specific (e.g. configuration) settings
> > should go here.
> >
> > The default way of will be non-interactive, essentially the
> > same as it is
> > now. However, emerge (and ebuild) will accept a --interactive
> > parameter.
> >
> > Whenever an ebuild needs to make any decision, it will call a
> > function
> > provided by emerge (or ebuild). So (I know this isn't a shell
> > script, but I
> > hate shell scripts!):
> >
> > # need to know whether to build qt interface
> > result = with(qt, "foo uses qt to such and such an effect.")
> >
> > The second parameter to the with function is the description of the
> > applicability of the With flag to this specific ebuild, and
> > what the ebuild
> > will do without it.
> > The ebuild will get a response, it doesn't need to know how
> > the decision was
> > made.
> >
> > The function will have two modes: interactive and noninteractive.
> >
> > In noninteractive mode (the default), the With answer will be
> > decided based
> > on the default value (from make.globals) and the user-defined
> > value if
> > present (make.conf).
> >
> > In interactive mode, activated by the --interactive command
> > line parameter,
> > the user will be asked to decide. This is where the
> > description of the flag
> > is used.
> > The user will see:
> >
> > # emerge --interactive foo.ebuild
> > Calculating dependencies.. done!
> >
> > >>> emerge foo to /
> >
> > Decide: qt (default yes, override No):
> > Description: an X interface library, used e.g. by KDE
> > Specifics: foo uses qt to such and such an effect.
> > [y/N]
> >
> > Note: not all flags need to be defined somewhere! If an
> > ebuild calls with on
> > an undefined flag, it needs to supply a default value. This
> > is the value
> > returned to it in noninteractive mode. The call would become:
> >
> > result = with(qt=yes, "foo uses qt to such and such an effect.")
> >
> > Dynamic definitions can be used as well as static, as defined earlier.
> >
> > The next thing to have is choice betwen mutually exclusive
> > With flags (this
> > is sorely lacking in the USE system).
> >
> > An ebuild might look so:
> > # Choose between mutually exclusive sound output interfaces
> > result=which(sdl_mixer, libmikmod, "Any one of these will do
> > for sound.")
> >
> > In interactive mode, the user will see:
> >
> > # emerge --interactive foo.ebuild
> > Calculating dependencies.. done!
> >
> > >>> emerge foo to /
> >
> > Choose: sdl_mixer, libmikmod (default sdl_mixer):
> > Specifics: Any one of these will do for sound.
> > [sdl_mixer/libmikmod]
> >
> > sdl_mixer is default, simply because it is named first. That
> > is, the ebuild
> > should pass the name of what it wants as default first.
> > Of course this will accept more than two flags at a time.
> > There is no Description (only Specifics) because this is not
> > a 'generic'
> > situation. An ebuild can request choice between any
> > combination of flags in
> > any order.
> > The last parameter passed to Which is thus the Specifics
> > string, all the
> > others are taken to be names of With flags.
> >
> > In non-interactive mode, the which function will simply
> > return the first flag
> > named, sdl_mixer in this example.
> >
> > As above, a flag undefined in make.globals and make.conf can
> > be used. No
> > default value for it is needed. You can just pass a list of flags.
> >
> > -------
> >
> > Subsystem: default values of mutually exclusive choices - groups:
> >
> > It is true that an ebuild can pass any list of flags and get
> > a result.
> > However, for noninteractive operation, it would be very
> > useful to assign
> > default results outside the ebuild (i.e. not by selecting the
> > order of flags
> > passed to which).
> > For this purpose, flags can be 'registered' in make.globals
> > (or make.conf) as
> > belonging to a group (or several groups). An example make.* entry:
> >
> > sdl_mixer=yes (audio-out)
> > Description of sdl_mixer.
> >
> > libmikmod=yes (audio-out)
> > Description of libmikmod.
> >
> > The entries thus classified will be arranged by group. The
> > first flag in a
> > group to be listed becomes the default choice for that group.
> >
> > A flag can be part of any number of groups, or none. Example:
> > libggi=!libsdl (audio-out,video-out)
> >
> > Whenever an ebuild calls which on flags that are all part of
> > one group (e.g.
> > audio-out), this becomes the default for an interactive
> > choice, and the
> > result returned from a noninteractive one.
> >
> > The ebuild doesn't need to know the name of the group, or
> > even that there is
> > one.
> >
> > And, if even this isn't enough, we could add a Groups section
> > in make.* which
> > would:
> > 1. Optionally define a group as a list of flags, even if
> > those flags don't
> > specify themselves as part of the group.
> > 2. Define the group's order.
> > 3. Provide an extra description of the group.
> > For example:
> >
> > <groups>
> > audio-out=libmikmod,sdl_mixer,libggi
> > The audio-out group is foobar foobar foo.
> >
> > In this example, the order in whch the flags are defined is
> > overriden, and
> > libmikmod is set to be the new default choice.
> >
> > The reason we have an entire list and not just a default
> > value is subgroups.
> > If an ebuild asks
> > result=which(sdl_mixer,mikmod,libggi,"select audio lib")
> > then it will get libmikmod (from noninteractive mode) since
> > it's first in the
> > list defined in make.*'s <groups>.
> > If however it says result=which(libggi,libmikmod,"subgroup
> > choice") then it
> > will get sdl_mixer because that's the best ('foremost')
> > choice left without
> > sdl_mixer.
> >
> > -------
> >
> > Comments welcome!
> >
> > --
> >
> > Dan Armak
> > Gentoo Linux Developer
> > Matan, Israel
> >
> > _______________________________________________
> > gentoo-dev mailing list
> > gentoo-dev@cvs.gentoo.org
> > http://cvs.gentoo.org/mailman/listinfo/gentoo-dev
>
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@cvs.gentoo.org
> http://cvs.gentoo.org/mailman/listinfo/gentoo-dev