Hi Ken,
----- Original Message -----
> At the recent PCP developers meeting there was a suggestion to
> 1. drop the binary format of the PMNS and
> 2. remove our dependence on cpp being installed to pre-process the
> ASCII PMNS before it is parsed.
>
> 1. makes sense because the "performance" optimization of the compiled
> PMNS was justified long ago when all client apps had to load the full
> PMNS from a local copy, but those days are long gone. Now, outside QA
> and some very rare uses, pmcd is the only one to load a PMNS and this
> only happens at pmcd start up or when a PMDA is added or dropped. So
> this is a sensible candidate for PCP 4.0.
>
> 2. is of a bit more immediate interest as it could be included in PCP
> 3.x. I've completed the code in libpcp to do
> - #include "file" and #include <file> (from $PCP_VAR_DIR/pmns)
> - stripping /* ... */ comments within the line and across lines
> - #define macro handling (v. simple linear symbol table)
> - macro substitution in the metric name and PMID
>
> But now I've hit an obstacle ... although what is done so far is
> enough
> for the installed PMNS in $PCP_VAR_DIR/pmns/root (which contains no
> cpp
> directives), the components of the PMNS from the various PMDAs (and
> some
> of the QA tests) include all of the above, _plus_
> - #ifdef ... #endif
> - #ifndef ... #endif
> - #undef
Those would be symbol table lookups (in your new symbol table) and
then treating the ifndef/endif body like a comment (or not) right?
Almost certainly that is completely understating the complexity. ;)
> Fortunately no one uses #if and I'm not going there!
>
> So now there are a number of options, and it is unclear which to take
> and I'd appreciate some feedback.
>
> A. Continue with the changes to date ... it is only code and not
> too hard ... but it is adding considerable (little used) bloat
> to libpcp
> B. Do A. and then rip all of the code out of libpcp and create our
> own mini-cpp application that is shipped and hidden in
> $PCP_BINADM_DIR
B gets my vote. Or roll it into pmnscomp if thats where it fits in
the chain (haven't looked closely enough). Do it "right" though,
even if it ends up just for pcp4 - don't let the "nice to have in
pcp-3.x" suggestion influence things too much.
> C. Take an existing cpp with a compatible open source licence and
> bundle that with PCP ... I've looked at the GNU one, but cannot
> easily see how to unbundle it from the morass of the gcc build
> environment. Another option is mcpp from
> http://mcpp.sourceforge.net/ which builds simply, but I have no
> idea about the quality of the code and it has a BSD-style
> licence. Are there other options in this category?
I remember looking into it once before too and not finding anything
suitable (this was a year or two back when looking into the native
Win32 port).
> D. Give up and maintain the status quo.
>
> What do you think?
IMO removing the cpp dependency is a good step forward, so I'd keep
at it if its not looking intractable at this stage.
cheers.
--
Nathan
|