| 1 |
On Fri, 10 May 2002, Bob Phan wrote: |
| 2 |
|
| 3 |
> As I said, I've already looked at it. And the format would be fine if |
| 4 |
> it was actually enforced. Here are some outliars that I have found. |
| 5 |
> |
| 6 |
> trusted |
| 7 |
> |
| 8 |
> No dash, no description, not even a blank one. Therefor, you cannot |
| 9 |
> tokenize based on dashes, since it is not gauranteed. Then you would |
| 10 |
> think, why not tokenize based on newlines? Here's another one from |
| 11 |
> that file. |
| 12 |
> |
| 13 |
> voodoo3 - Adds support for 3Dfx's Voodoo3 video chipset, else |
| 14 |
> defaults to Voodoo4/5 support if not in USE |
| 15 |
> |
| 16 |
> That eliminates being able to tokenize based on newlines. Basically |
| 17 |
> use.desc is really only useful for users. My suggestion would be to |
| 18 |
> either clean this file up to conform to some form of guideline, or to |
| 19 |
> make a mirror copy (ie _not_ to remove but to add in addition to) an |
| 20 |
> XML file with the same information. |
| 21 |
|
| 22 |
This regex handles those cases: |
| 23 |
|
| 24 |
^([a-z0-9]+)[ \t]+-.* |
| 25 |
|
| 26 |
> I've already written a script that can mine out all optional use |
| 27 |
> statements. Adding the functionality to dynamically go backwards |
| 28 |
> through the dependancy tree would be trivial. |
| 29 |
> |
| 30 |
> I just wanted to get a sense from all of you out there as to what you |
| 31 |
> would vote for as a better standard for keeping a separate list with |
| 32 |
> this information, which I or anyone can maintain. It would be really |
| 33 |
> useful for a few scripts I've been meaning to write, such as a GTK+ |
| 34 |
> based auto USE var generator. And a "what options are available to me |
| 35 |
> in this ebuild before I install it" script. I'm also sure others |
| 36 |
> would find some use for such information to be stored in a more usable |
| 37 |
> format. |
| 38 |
|
| 39 |
I used to think the format should be changed. If the use.desc file is |
| 40 |
supposed to be only machine-readable, it certainly should be changed. |
| 41 |
|
| 42 |
However, if users are supposed to read that file as well, we should not |
| 43 |
change it, as it is currently easy enough to parse and extremely easy |
| 44 |
to read. |
| 45 |
|
| 46 |
There are currently 255 out of 2959 ebuilds that use undocumented use |
| 47 |
flags. These use flags will have to be moved into use.desc. |
| 48 |
|
| 49 |
There has been discussion of an IUSE var for each ebuild, that lists the |
| 50 |
use flags that an ebuild can avail itself of. This would ease up the task |
| 51 |
of collectiong these options. In the meantime, the regex |
| 52 |
|
| 53 |
[^#]*use ([a-z0-9]+).* |
| 54 |
|
| 55 |
does the trick. |
| 56 |
|
| 57 |
|
| 58 |
Karl T |
Archives