harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [classlib] Preprocessor
Date Mon, 30 Oct 2006 18:31:22 GMT

Tim Ellison wrote:
> Etienne Gagnon wrote:
>>> Chris Gray wrote:
>>>> For JavaME I think it's the only way we'd be able to maintain a single
>>>> source tree. We need to be able to "#ifdef out" references to classes
>>>> we don't have, methods we don't implement, etc..
>>>> That much being said, I don't have a recommendation for a tool to use.
>>>> Java syntax is sufficiently C-like that cpp is probably do-able, but
>>>> we'd probably stumble over a whole series of gotcha's, and cpp isn't
>>>> exactly [deity]'s gift to preprocessing anyway. Maybe one of the
>>>> aspect-oriented tools (with which I am not at all familiar) could be a
>>>> better bet?
>> You could always do "clean" source-to-source processing using
>> SableCC...:-)  Java is a nice language to parse, so you could do some
>> clean parsing, instead of the dumb "unstructured text" replacement of
>> preprocessors.
>> Actually, if all you need if "ifdef'ing out" undesirable references, it
>> could be done by "hiding" modification directives in structured
>> comments,  so that these comment remain "javac" invisible.  This way you
>> could make it such that:
>> 1- Plain source compilation -> j2se .
>> 2- Structured processed source compilation -> j2me .
> I agree, ensuring that the original source remains compilable can be a
> great benefit.
> Besides in-lining #ifdef's you can also maintain look-aside files with a
> description of the smaller configurations.  That helps to avoid code
> clutter though of course you may prefer to be marking-up the code
> in-line if it is not simply removing whole types/methods.


> The other thing to remember is that methods that appear in the smaller
> configurations must only be implemented in terms of methods that appear
> in the smaller configurations.  For example, you may have to rewrite
> regular IO to not be implemented in terms of NIO so that it remains
> viable in configurations that don't have NIO.  In Harmony we have a
> common 'platform IO layer' used for both modules.
> Where you do go through a source-to-source transform stage it helps of
> you can collaborate with the second-stage compiler to pass through
> original line number info (a la JSR45) otherwise debugging gets a bit
> tiresome.

Right, except I could imagine having an IDE plugin that deals with this 
for you - you edit and debug using the processed code, which is what the 
line numbers will correspond to...

> Regards,
> Tim
>> If you need it, there are 2 or 3 Java 1.5 grammars available for SableCC
>> (different parsing approaches, not different syntax!).  As I said, Java
>> is a pleasure to parse when compared to C & C++.
>> It's just an idea, of course...  [I know that people can start religious
>> wars about pre-processing; that's why I am suggesting a clean approach,
>> so that j2se people don't have to pre-process].
>> Etienne

View raw message