On Mon, Aug 22, 2011 at 10:44 AM, SF Markus Elfring < [email protected]> wrote:
> > I'd like to have a sort of C equivalent to this Perl module which > > can do 'round trip' parsing of Perl source code into a structured, > > hierarchical format, and back into Perl source code: > > http://search.cpan.org/~adamk/PPI-1.215/lib/PPI.pm > > How do you think about the applicability of tools like the following for > your > use case? > - OpenGrok > - cscope > - LXR Cross Referencer > I have looked at those tools and dismissed them because the info they provide does not appear detailed enough to e.g. exactly re-create the C source file in question; so called round trip parsing. And some of them like OpenGrok are quite heavy weight in terms of what you need installed to make it do its regular job. The only two possibilities that I have come up with so far are Coccinelle and maybe clang (but I'm no sure yet how to make it give up its C tree with or without compiling fully). More about what I want to achieve: Whereas a tool like Coccinelle allows humans to come up with patches to make changes to source files, I would like software to be able to patch C sources on the fly. For example, I might have a set of C source files which compile and run perfectly fine. My build system might allow me to create a release build and a debug build. I could permanently instrument the C source with macros which only get compiled into the debug build (this is a great technique which I use today but the only main downside is that it makes the source code more voluminous because of all the instrumentation). What if the instrumentation could be added on-the-fly? I.e. the build system generates a new foo.c file just for the debug build. In this case I would get the best of both worlds; slim looking source files and 'permanent' (now in the sense that it can be automatically regenerated) debug instrumentation. In order to automatically add the debug instrumentation to the debug foo.c file then my script needs to know all about the original foo.c file. It's also important that the extra instrumentation added does not change the line numbering otherwise it will be difficult for me to match either compiler errors or run-time assert line numbers with the original foo.c file which is the only file that I would be editing for development. Does this make any more sense now? Thanks, Simon > Regards, > Markus >
_______________________________________________ Cocci mailing list [email protected] http://lists.diku.dk/mailman/listinfo/cocci (Web access from inside DIKUs LAN only)
