Community
Participate
Working Groups
As you probably know, we're planning to use the Eclipse java compiler as the front end to GNU gcj (http://gcc.gnu.org/java/). This work is complete and will be merged to the GCC svn trunk sometime in the near future. In order to ease the mismatch between eclipse-style and "GNU style" command line argument parsing, I've written a new "GCCMain" class that works in a way more suitable for invocation from gcc's internals. It also has some options which are used to make sending class files from ecj to the next gcj pass ("jc1") simpler: in particular class files can be written into a couple of jars. The changes to Main.java are mostly along the lines of refactoring to reduce the amount of code duplication in GCCMain. I'd like to see this committed to eclipse.org's cvs, so that GCC doesn't need to keep its own fork of ecj around. I'm happy to change things as you like to this end.
Created attachment 51374 [details] patch to refactor Main and add GCCMain
Olivier - good timing with ongoing jsr199 changes
I can release the change concerning the Main class, but we cannot host the GCCMain class. This goes beyond the scope of the batch compiler.
Released Main class changes for 3.3M3.
Thanks for accepting what you have. Is there a way I can change the code to make it fit within the batch compiler's mandate? I looked at rewriting GCCMain.java as a pure wrapper -- something that would translate command-line arguments and then simply invoke the existing main(). However, this is tricky for two reasons. First, it is more convenient inside GCC to pass jar files around rather than do the bookkeeping for directories full of class files. Second, we need to be able to differentiate between "class files which are a direct result of this compilation" and "class files which were generated as a side effect of this compilation". That is why there are two different output jar file command line arguments. I think if this functionality was available in the ecj driver I could rewrite GCCMain in a different form. Or ... I'm willing to do something else, too, I'm just out of ideas.
We should think about adding compilation participant to the batch compiler. In other words, make the batch compiler extensible. The problem here is that we have limited resources and this is not a priority. Moreoever we do have existing users of our batch compiler that we don't want to break by reorganizing the internal code too much. If you have any proposal in this direction, feel free to open a new bug report about extending the batch compiler. Thanks for your input.
In Plan B the idea would be to simply add a couple new command line options to the existing batch compiler. It would not be a huge amount of code, it would be fairly well-defined, and I can't see how it would impact existing users of the batch code. This is definitely a priority for me, fwiw. We'll be merging our development branch to GCC trunk soon (next month or so), and all GCC developers will need an easy-to-download ecj jar that can be dropped in. Also the various Linux distros using gcj will be switching to this. My main concern about maintaining GCCMain.java outside the eclipse tree is keeping it up-to-date wrt changes going on in ecj. Also there's the question of how to efficiently get the code out to the distros. Adding command line options would let us finesse this. Another plan we're kicking around is to set up our own repository with a copy of ecj.
> My main concern about maintaining GCCMain.java outside the eclipse tree > is keeping it up-to-date wrt changes going on in ecj. Also there's the > question of how to efficiently get the code out to the distros. > Adding command line options would let us finesse this. Another plan > we're kicking around is to set up our own repository with a copy of ecj. We understand this, but having it inside the Eclipse tree is opening the door to others that would want to extend the batch compiler. We don't change the internals of the batch compiler often. I can let you know when we do it to be sure that you are in synch. I guess this is the best we can do. We already have existing users of the batch compiler that we don't want to break (Tomcat for example). I released the changes you made in the batch compiler so your GCCMain should work without a change with current HEAD contents.
Released for 3.2.2. Philippe, please tag is as 3.2.2. This will allow them to use 3.2.2 in gcj.
+1 for 3.2.2
Tom, Could you please double-check that you can compile your GCC driver with the 3.2 maintenance stream?
Verified for 3.3 M3 using build I20061030-0010
(In reply to comment #11) > Tom, > > Could you please double-check that you can compile your GCC driver with the 3.2 > maintenance stream? Tom's on vacation and he asked me to verify this for him. GCCMain.java does in fact compile with the R3_2_maintenance branch. Thanks.
Verified for 3.2.2 using build M20070112-1200.
Tom or Ben, Could you please double-check that the existing code is still inline with what you expect? Would you have a test case to provide that we could use as a regression test? Thanks, Olivier
