incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Bergmann <>
Subject Re: [code] stuck at offapi on
Date Tue, 30 Aug 2011 12:51:00 GMT
On 30.08.2011, at 14:40, "Pedro F. Giffuni" <> wrote:
> --- 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 :(.

We already have a lexer for .idl, implemented with flex.  It's more like, upon an #include
directive, idlc need not literally include the given file's content but could rather obtain
the necessary information about the entity defined in the included file from the types.rdb
database, more or less.

  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message