| 1 |
On Fri, Mar 26, 2010 at 10:26:46AM +0200, Petteri RRRty wrote: |
| 2 |
> On 03/26/2010 04:40 AM, Sebastian Pipping wrote: |
| 3 |
> > hey there, |
| 4 |
> > - have you looked into python module shlex [1]? |
| 5 |
> > could that be of use? |
| 6 |
> |
| 7 |
> It could maybe be used for inspiration but I don't think it's nowhere |
| 8 |
> near being able to parse ebuilds. |
| 9 |
|
| 10 |
Avoid it for inspiration- the state machine at it's core is extremely |
| 11 |
buggy in parsing and also a serious PITA to decipher. shlex, once |
| 12 |
heavilly monkey patched, is useful for make.conf parsing at best |
| 13 |
where it's just simple var assignment- all but the simplest variable |
| 14 |
interpolation is unsupported by it also. |
| 15 |
|
| 16 |
A better source for inspiration of parsing rules is- |
| 17 |
http://www.pkgcore.org/trac/pkgcore/browser/pkgcore/pkgcore/ebuild/filter_env.py |
| 18 |
it actually can parse all of bashes oddities although it does not |
| 19 |
generate an AST (nor does it always know what's it parsing, nor does |
| 20 |
it exactly *know* what it's parsing (while it knows how to identify |
| 21 |
where the end of a variable interpolation occurs, that doesn't mean it |
| 22 |
knows it's a variable interpolation). |
| 23 |
|
| 24 |
|
| 25 |
> Any way C/C++ implementation would be |
| 26 |
> useful if we want all PMs to be able to make use of it. |
| 27 |
|
| 28 |
Fully agreed- this is what was intended/attempted originally, I just |
| 29 |
bailed on it due to at the time it turning into a way larger project |
| 30 |
then I had time for. |
| 31 |
|
| 32 |
It's the proper solution- at least via pkgcore source, there already |
| 33 |
is a lot of intermediate solutions. That part is done- a better/final |
| 34 |
solution is needed now. |
| 35 |
|
| 36 |
|
| 37 |
Sidenote, berkholz brought up something- anyone talked to Chett |
| 38 |
(upstream) about our intentions on this proposal? |
| 39 |
|
| 40 |
~harring |
Archives