1 |
On Friday 26 August 2005 17:11, Paul de Vrieze wrote: |
2 |
> On Friday 26 August 2005 16:58, Ciaran McCreesh wrote: |
3 |
> > On Fri, 26 Aug 2005 14:50:52 +0200 Paul de Vrieze <pauldv@g.o> |
4 |
> > |
5 |
> > wrote: |
6 |
> > | ps. People please be aware that this is still alpha in the sense of |
7 |
> > | not being complete. For better working it should probably support |
8 |
> > | if statements properly, and at least do variable substitution. It |
9 |
> > | would mean that the parser would have to retain a state etc. |
10 |
> > |
11 |
> > Isn't this pretty much a waste of time if it can't handle all the |
12 |
> > code in versionator? We're trying to move people away from ugly |
13 |
> > unreliable manual substitutions towards readable, maintainable code |
14 |
> > using the eclass... |
15 |
> |
16 |
> With lack of variable substitution support I mean that it just forwards |
17 |
> the variable substitutions to the calling application (output). It |
18 |
> should probably also be made more aware of the variables that are |
19 |
> allways extended like USE and DEPEND. |
20 |
|
21 |
I just checked the versionator eclass though, and indeed it wouldn't |
22 |
support it. Versionator uses functions inside the variables. The parser |
23 |
does not parse functions at all beyond being able to determine their end. |
24 |
Perhaps it would be best to handle versionator specially and internalize |
25 |
the functions. While it is possible to interpret the bash functions this |
26 |
would mean full bash function duplication, make the parser more complex |
27 |
and diminish the speed of the parser. |
28 |
|
29 |
I could even do this function mimicking in such a way that nonsupported |
30 |
functions automatically get signaled as requiring compatibility mode |
31 |
(parser is uncertain about it's results, and the old parser should be |
32 |
used). |
33 |
|
34 |
Paul |
35 |
|
36 |
-- |
37 |
Paul de Vrieze |
38 |
Gentoo Developer |
39 |
Mail: pauldv@g.o |
40 |
Homepage: http://www.devrieze.net |