Re: FYI: submitted ecj patch upstream

[Joel Dice <dicej at mailsnare dot net>]

On Mon, 9 Oct 2006, Andrew Pinski wrote:

> > Tom> I've submitted my ecj patch to eclipse.org.  This patch adds the new
> > Tom> gcc-specific driver to ecj, and is needed by the work on the
> > Tom> gcj-eclipse branch.
> >
> > Tom>     https://bugs.eclipse.org/bugs/show_bug.cgi?id=159641
> >
> > So, we've had a minor setback here -- the eclipse maintainers accepted
> > part of this patch, but not all of it.
> >
> > I looked at writing an "ecj1" driver that does a pure translation of
> > command-line arguments, but I don't think that is possible due to our
> > need to differentiate between "primary" and "dependency" classes on
> > the output end.
> >
> > My current plan is to make a new cvs repository somewhere, import the
> > upstream ecj, and apply the needed patch.  Then we can do periodic
> > imports from upstream and make our own ecj.jar available.
> >
> > Another idea would be to maintain just "GCCMain.java" separately.  If
> > we went this route I think we would make our own "ecj1.jar", holding
> > just this class, available, and have users download the eclipse.org
> > ecj.jar separately.
>
> I think this is a very very bad idea as it means we have to go out
> and grab too many things.
> Why not just create a C program that converts the options and place
> that into the GCC repo and have it build with the rest of the compiler?
>
> Using Java too much is not a good thing.

Are there any legal or technical barriers to maintaining GCCMain.java in 
the GCC source tree and generating ecj1.jar during the build process?  I 
quick scan of GCCMain.java suggests there's more to it than simply 
converting options.

 - Joel