--- On Tue, 8/30/11, Stephan Bergmann wrote:
... > > > > This is an important question. If we need another > > preprocessor there are options(1), but we need to now > > why. > > At least for idlc, I think the best solution would be to > get rid of a C preprocessor completely. Even if > de-facto (if not also de-jure) .idl files have always been > passed through a C preprocessor, so in theory could make use > of all the C preprocessor's features, this has practically > always only been used for plain #include <…> or > #include "…" stuff (plus internal and external header > guards, #ifndef XXX/#define XXX/.../#endif and #ifndef > XXX/#include "YYY"/#endif), I think. > OK, thanks for explaining. The idea of just ripping of code that we don't like is rather scary but i this case I guess it could work at the expense of some robustness. > So, it should be possible---without breaking backwards > compatibility in practice---to change idlc so that it > ignores all #… lines except for #include lines, which it > then handles via a more efficient mechanism than textual > inclusion. > This sounds like a job for embedded ucpp under the "lexer" mode.[1] It's pretty small and very manageable, plus we need a lexer anyways. Sorry my C-fu is not good :(. > Would still have to have a look at soltools/cpp, though... > This is probably easier to replace since it's a standalone tool. In addition to mcpp, the Portable C compiler[2] also includes a preprocessor that should be comparable to the one in lcc. hth, Pedro. ps. Repeated here for convenience: [1] http://code.google.com/p/ucpp/ [2] http://pcc.ludd.ltu.se/
