Re: [gentoo-dev] Parsable list of all use variables.

[Bob Phan]

On Fri, 10 May 2002, George Shapovalov wrote:

> > it was actually enforced.  Here are some outliars that I have found.
> I've corrected these two (added description to trusted and got rid of \n for
> voodoo3).
>
Cool. That eliminates my problems with the original format.

> I would like to keep file format as simple as possible. It might be needed at
> some point to have a very basic function implemented that would be desirable
> in barebones system. It is not a good idea to have to include XML parsers
> just because one file needs to be parsed (thats the same reason as the one
> behind plain-text human readabla/easily parsable format for config files for
> majority of the apps).
> I think it is just a matter of enforcing certain use.desc format. As it stands
> now it can be parsed based on " - " key. I am going to raise this issue and
> suggest another separator (dash is used quite frequently in package names and
> some times in description). What do you think about "|"? Also ":" might be
> more logical, but it can naturally occure in description.

I agree completely.  My original reasoning for XML was enforcing the
formatting and perhaps adding more information.  But for my purposes,
what is there should be good enough for now.  And actually, it doesn't
matter if there is a - in the description as long as there aren't any
in the use variables themselves.  You can split on - and request 2
tokens, which would put the second half, dashes and all, in the second
array item.

> > I've already written a script that can mine out all optional use
> > statements.  Adding the functionality to dynamically go backwards
> > through the dependancy tree would be trivial.
> Nice, could you submit this script to bugs.gentoo.org?

Yup, I'll tidy it up, add docs and an ebuild, and ship it off to
bugzilla tonight.

> > I just wanted to get a sense from all of you out there as to what you
> > would vote for as a better standard for keeping a separate list with
> > this information, which I or anyone can maintain.  It would be really
> I do not object the existence of such list. However I think it should not be
> hand-maintained. Since you will have a script which will fish for referenced
> use variables, better approach would be to have a tool that could generate
> this back-reference file per request. My experience with duplicating
> information is that things go insane if there is no defined authoritative
> entity and in this case collection of ebuilds clearly should take precedence.
> BTW similar tool can be used to check validity of use.desc.

Good idea.  Currently, all the data it gathers _is_ from the ebuilds.
That way, the list of use vars it comes up with can be checked against
use.desc to make sure use.desc is not missing anything.  That should
be simple enough to add.  I had no intentions of hand maintaining
anything :).

-- 
/*
 * Bob Phan <bob@××××××××××××××××.net,rphan@××××.com>
 * Computational Chemistry Informatics
 * Neurogen Corporation
 * [phone] x4645
 *
 * To understand recursion, you must first understand recursion.
 */