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 - CHECKPOINT
Date Thu, 02 Nov 2006 04:27:52 GMT
Cool.  Any Eclipse Plugin gurus here that could create a <whatever it's 
called in eclipse speak... perspective?> that has two edit panes, one 
with the code w the preproc directives in it, and one that is the result 
of the preproc given some defines?

geir


Nathan Beyer wrote:
> I've read a few articles about J2ME development using Antenna, which
> has a Java preprocessor task for Ant [1]. The Mobility Pack for
> NetBeans includes a Java preprocessor, which it claims is
> similar/based on Antenna [2].
> 
> I still feel a little dirty about the thought of preprocessing Java
> source, but I guess it's done.
> 
> -Nathan
> 
> [1] http://antenna.sourceforge.net/#preprocess
> [2] http://www.netbeans.org/kb/50/quickstart-mobility.html
> 
> On 11/1/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>>
>>
>> Etienne Gagnon wrote:
>> > Geir Magnusson Jr. wrote:
>> >> There's caching too, I think.  LogCache4J
>> >>
>> >> What I meant was that it didn't seem like we came to a conclusion 
>> on it
>> >> - that if we had a general pre-processing solution, we could use that
>> >> too for logging, rather than have two.
>> >>
>> >> The actual use-cases will help figure this out.
>> >
>> > Here two typical some use cases, and some proposed solutions:
>> >
>> > Problem
>> > -------
>> > logging, and other situations where you really don't want to put the
>> > "additional" source code in the main source files
>> >
>> > Solution
>> > --------
>> > use aspects  (Plug: you might want to give a look at the optimizing abc
>> > compiler)
>> >
>> >
>> > Problem
>> > -------
>> > supporting a different API specifications/versions, such as j2me and
>> > j2se1.4, in addition to the "main" version (e.g. j2se1.5)
>> >
>> >
>> > Solution
>> > --------
>> >
>>
>> Right - these were the main hypotheticals that started this whole thread
>> off - I was thinking more about a definite example, like a given class C
>> has a different implementation of method M in Java5 than in Java6.
>>
>> Even if we walk through this with a clear example simple manual process,
>> it will be enlightening.
>>
>> > This is a trickier problem.  We can divide the problem at two main 
>> levels:
>> >
>> > 1- file/directory level
>> > 2- source-code level
>> >
>> > At the file/directory level, each version (e.g. j2me, j2se1.4, ...)
>> > might include additional files (relative to the main version), and 
>> might
>> > not include some files of the main version.  In other words, j2me might
>> > not contain database APIs.
>>
>> Yep
>>
>> >
>> > Managing file inclusion/exclusion can be done in various ways.
>> >
>> >  a) ant based:  use distinct ant (sub-)files for each version.
>> >
>> >    The problem is that IDEs (e.g. Eclipse) will most likely show some
>> >    of the excluded files in its class/files browser.  This wouldn't be
>> >    very elegant.  It also implies "always" compiling through ant files.
>> >
>> >    Of course, one could develop Eclipse-specific configuration files to
>> >    mimic the inclusion/exclusion of ant files, but then, this opens the
>> >    door for discrepancies between ant vs eclipse inclusion/exclusion
>> >    lists.  I don't like it.
>> >
>>
>> Me neither.
>>
>> >  b) custom-tool based: the custom processing tool I proposed could also
>> >    parse inclusion/exclusion lists, and use these lists to move files
>> >    around, in addition to processing the content of unmoved files.
>>
>> I'm not sure anything needs to be moved.
>>
>> >
>> >    For example, if class X of the main version is not part of j2me,
>> >    "process(j2me)" would move this file to a subdirectory ".streams/".
>> >
>> >    If a class Y is not in the "main" version (the one used for "svn
>> >    ci"), it resides in subdirectory ".streams" in the trunk.
>> >    "process(j2me)" moves this file into the normal directory.
>> >
>> >    As for IDEs, now you can configure them to automatically exclude
>> >    ".stream/" directories.
>>
>> This would get messy.  I'd rather just have a plug-in that reads a
>> description file for version X and just doesn't show me what isn't part
>> of version X.
>>
>> >
>> >    Inclusion/exclusion could be managed in two ways:
>> >    1- the processing tool could look for inclusion/exclusion list 
>> files,
>> >       such as "j2me.inclusion, j2me.exclusion, main.inclusion,
>> >       main.exclusion, etc."
>> >
>> >       This would lead to the best performance (for process(X)), yet it
>> >       does require much manual update of inclusion/exclusion lists, 
>> with
>> >       all the discrepancies that result from human mistakes while
>> >       updating these files.
>> >
>> >    2- (my preferred way), directives, at the beginning of the source
>> >       code would indicate whether a file is included in a version or
>> >       not.  Depending on target, the file would be moved to the
>> >       appropriate directory (normal, ".streams").
>>
>> Either one - the nice thing about #1 over #2 is that you can actually
>> look at it to get a summary.  But you can generate the same info w/ a
>> tree walk, I suppose.
>>
>> >
>> >
>> >     Of course, there's also the problem of non-source files, i.e.
>> >     resources.  IMO, resources could be managed using specific
>> >     directories (".main/", ".j2me", ".j2se1.4") and a ".shared/"
>> >     directory with symbolic links in the specific directories.
>> >
>>
>> This is getting messy.
>>
>> >
>> > As for source-level management, you would use my proposed processing
>> > tool to view the source files with the right spectacles [as Tim said so
>> > elegantly:-)].  For "development targets", it is important that:
>> >
>> >  revert(process(X, target)) => X
>> >
>> > By "development target" I mean a target that is meant for Harmony
>> > developers in prevision of reverting "modified code" to a format
>> > suitable for "svn ci" (i.e. revert to "main" target).
>> >
>> > For comfortable IDE development, one could imagine that the IDE editor
>> > can reduce to "one-line visible" comments (or better, specially
>> > formatted ones) so that it gives you the impression that you are really
>> > wearing target-specific spectacles.  [I know Eclipse allows for such
>> > things already].
>> >
>> > To release code, one would apply:
>> >
>> >  process(X, release-target) => Y
>> >
>> > Now, it is important to understand that Y, in this case, is NOT 
>> suitable
>> > for doing any modification as
>> >
>> >  revert(Y) => Kaboom!  (The tool will simply report that it can't do 
>> it;
>> >                         it won't crash.)
>> >
>> > Yet, I think that it would be important that the processing tool leaves
>> > "markers" in Y, so that we could also have a tool to help finding the
>> > canonical source line of a reported bug:
>> >
>> >  revertLine(Y, L') => L  (where L' is a line reported by end-developer,
>> >                           and L the related line in "svn").
>> >
>> > Markers would be short single lines comments, so the end-developer
>> > annoyance would be kept minimal.
>> >
>> >
>> > What do you think?
>>
>> This is what I thought we were talking about all along - basically
>> starting w/ the full source, and pre-process to the "canonical" source
>> for the target version.
>>
>> However, I don't understand why I can't go backwards, modulo some manual
>> merging if needed.
>>
>> For example, if I have X and release-version, I should be able to take a
>> Y' and resolve back to X'.  There are problematic cases.  For example,
>> in psuedo code and psuedo directives :
>>
>> X :
>>
>>    public void woogie() {
>>
>>      firstLineJava;
>>
>>     #ifdef(Java 6)
>>          middleLineJava6;
>>     #endif
>>
>>      lastLineJava;
>>    }
>>
>> then
>>
>> process(X, Java5) outputs
>>
>>
>> Y:
>>
>>    public void woogie() {
>>
>>      firstLineJava;
>>
>>      lastLineJava;
>>    }
>>
>>
>> Now, if I make a Y'
>>
>>    public void woogie() {
>>      newLineJava5;
>>
>>      firstLineJava;
>>
>>      lastLineJava;
>>    }
>>
>> I should be able to
>>
>>    revert(X, java5, Y') -> X' such that
>>
>> X' :
>>
>>    public void woogie() {
>>
>>      #ifdef(java5)
>>         newLineJava5;
>>      #endif
>>
>>      firstLineJava;
>>
>>     #ifdef(Java 6)
>>       middleLineJava6;
>>     #endif
>>
>>      lastLineJava;
>>    }
>>
>> No problem.  (Maybe a flag that tells revert that the change is for all
>> versions....)
>>
>> However if
>>
>> Y' :
>>
>>    public void woogie() {
>>
>>      firstLineJava;
>>
>>      newLineJava5;
>>
>>      lastLineJava;
>>    }
>>
>> then I'm not sure if X' is
>>
>>    public void woogie() {
>>
>>      firstLineJava;
>>
>>      #ifdef(java5)
>>         newLineJava5;
>>      #endif
>>
>>     #ifdef(Java 6)
>>       middleLineJava6;
>>     #endif
>>
>>      lastLineJava;
>>    }
>>
>> or
>>
>>    public void woogie() {
>>
>>      firstLineJava;
>>
>>     #ifdef(Java 6)
>>       middleLineJava6;
>>     #endif
>>
>>      #ifdef(java5)
>>         newLineJava5;
>>      #endif
>>
>>      lastLineJava;
>>    }
>>
>> In this case it may not matter, but either way, simply doing a
>> merge-failure style >>>>>> marker should make it clear to the developer
>> that some assistance is needed.
>>
>> I also realize that this is a toy simplistic case :)
>>
>> >
>> >
>> > I am really offering to develop this custom tool.  Just help me 
>> identify
>> > various Harmony needs I might have missed!
>>
>> Cool! Go for it!
>>
>> >
>> > Of course, this tool is not the best solution to ALL problems, yet, so
>> > far, I think that it seems to best address the problem of supporting
>> > various API versions.
>>
>> lets sketch out a few real examples, say between Java5 and Java6, and
>> work them through.  That should give you a good idea on what the tool
>> will be required to do.
>>
>> geir
>>
>>
> 

Mime
View raw message