I do not have an easy answer for you, perhaps one of the Wizards will.
On Thursday, Jun 3, 2004 [EMAIL PROTECTED] said:
> Hi,
>
> I'm almost finished with the script (the stripped down test case
> is on the bottom of this mail) which parses cpp-preprocessed output.
>
> The pecularity of parsing cpp-output is that if the cpp-processed
> file #includes a file, then cpp prints a linemarker line, like:
>
> # 1 "..\\mmstorageiface\\group\\bld.inf" 1
So, in other words, this can appear at the top-most parsing level.
>
> In my script I keep track of the current working directory and
> update it (in the updateCurdir() below) whenever a linemarker
> rule (with flags 1 or 2) triggers. The script works fine for
> the most of my input files, but there are few that break it.
>
> There are 5 kind of sections started by the "section" terminal.
> And the problem comes when the input file #includes another
> file, while being in the middle of one section, like here:
>
> PRJ_MMPFILES
> MMSTORAGEIFACE.MMP
> ..\GROUP\PNMSG.MMP
> # 72 "bld.inf" 2
> makefile ..\group\convcolor.mk
So in other words, this can *also* appear INSIDE a subordinate parsing level.
Hmmmm...
>
> The section above is started by the "PRJ_MMPFILES" terminal,
> then 2 paths to .mmp files are coming and then (unexpected)
> the cpp-linemarker comes before the last path.
>
> What could I do now to solve this problem, please?
Seems to me like there is no "obvious" solution except to put it in two
places :-).
>
> I can't just skip the linemarker comments as in P::RD::FAQ.
>
> I also don't want to prepend the linemarker subrule to each
> of the 5 section rules, like here:
>
> prj_mmpfile: /PRJ_MMPFILES\b/i
> (linemarker | mmpfile[\%::prj_mmpfiles])(s?)
OK, so then put the rule in mmpfile, it'll catch all five cases...
mmpfile: makefile(?) path special(?) {
::storeMmpPath($arg[0], $item[1]->[0], $item{path}, $item[-1]->[0]);
} | linemarker
>
> because that would make my script really unreadable and
Unreadability is in the eye of the beholder. I like using white space and
alignment to make things readable, but that is just MHO.
> because I'll have to add an if-statement into each of the
> 5 actions in order to distinguish if it was triggered by
> another linemarker or by the normal section entry.
Yep, sounds like you will, because the semantics subtly change between the
two cases and this sounds like a pathologic thing to me based on the
semantics of the input data.
>
> Any advices please?
Since I'm talking and I can't shut up, I have to offer my opinion about your
coding style wrt(1) side effects.
Inside of parsing rules, you update your internal tables "early" (i.e. the
chdir rule triggers an update as soon as its encountered). This can be fine
or it can cause unfortunate side effects which become parse dependent,
particularly if you use negative look-ahead. There is *bound* to be one
single corner case in some friggin' windoze file somewhere that will cause
you to spend hours in debug before you end up slapping your forehead and
shouting "Doh!".
I would advise that all side effects be implemented at the "highest possible
level" i.e. when you are Real Sure that you have the right data. At that
point it is "safe" to update the tables. You are not making your own data
structure, which is OK, but it can make it somewhat complicated when you go
back to make some kind of data dependent update. I would recommend that all
side effects be implemented in the innfile rule because it is the only place
that you are Real Sure of what you have.
Also another coding trick that makes it easy to maintain code is to have
keyword rules "programmable":
use constant GRAMMAR => q(
{my @makefile_keywords=qw(GNUMAKEFILE MAKEFILE NMAKEFILE);
...
makefile: /\w+\b/
{
if (grep(lc($item[1]) eq $_,@makefile_keywords)) {
$item[1]
} else {
undef
}
}
...
This way when you discover that you have to add Just One More Keyword, you
just put it in the appropriate list.
(1) wrt: With Respect To - at Intel we love TLAs - Three Letter Acronyms
>
> Regards
> Alex
>
>
--
Intel, Corp.
5000 W. Chandler Blvd.
Chandler, AZ 85226
--
Intel, Corp.
5000 W. Chandler Blvd.
Chandler, AZ 85226
