> I am really offering to develop this custom tool. +1 For me this is a key message. For sure that would be a nice tool. Does it worth to dig use cases even more? Do we plan to develop j2me here at Harmony?
Etienne, I wonder if it worth to have SableCC itself exposed as a part of Harmony. Say, you post a JSR for compiler generation API and add an appropriate package to Harmony JRE. With best regards, Alexei Fedotov, Intel Java & XML Engineering >-----Original Message----- >From: Etienne Gagnon [mailto:[EMAIL PROTECTED] >Sent: Wednesday, November 01, 2006 4:51 PM >To: harmony-dev@incubator.apache.org >Subject: Re: [classlib] Preprocessor - CHECKPOINT > >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 >-------- > >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. > >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. > > 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. > > 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. > > 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"). > > > 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. > > >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? > > >I am really offering to develop this custom tool. Just help me identify >various Harmony needs I might have missed! > >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. > > >Etienne > >-- >Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/ >SableVM: http://www.sablevm.org/ >SableCC: http://www.sablecc.org/
