This is the mail archive of the frysk@sources.redhat.com mailing list for the frysk project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Build Breakage


Hi,

On Mon, 2006-06-26 at 01:41 -0500, Phil Muldoon wrote:
> Wu Zhou wrote:
> > I heard that gcj's frontend will switch to ecj (correct me if I am wrong).  
> > Does this have any impact for the building process of frysk.  If it is, I 
> > guess we need to update the build document page after that.
> >   
> Right now if you have eclipse-ecj installed, it uses ecj to build Frysk. 
> It does a pretty good job at catching warnings that turn out to be 
> "gotchas".

Yes, the gcj .java source frontend seems to accepts some invalid code.
The ecj warning check pass in the makefiles is a good thing.

A next generation gcj will only use ecj as an "pre-processor" pass
for .java -> .class (or *.java -> .jar) generation and then it will just
compile the .class files to .o files instead of doing the *.java -> .o
compilation directly itself. This integration work seems to be going
fairly well. But it is still on a separate branch, it will not yet be in
gcc 4.2. But maybe some distros will ship an experimental release in the
next couple of months. This work (plus new gnu classpath work) will
bring us some interesting 1.5 libraries and language constructs like
generics, annotations and enumerations. But it seems premature to depend
or plan for those already. I also assume there will be a transparent way
to move a single gcj invocation into a new two pass ecj -> gcj
invocation to generated the native code. So in theory we wouldn't really
have to change the build system at all.

> I'm not sure if eclipse-ecj brings down the whole eclipse dependency 
> chain on you, though.

No, the ecj bit is fairly independent of most of the rest of eclipse.
And the checking in the frysk build system that uses it is really worth
it, so please install this if you haven't yet!

> As far as build policy, my personal watchword is build before you 
> check-in, and build after.

Yes, for some projects I have a separate anonymous CVS checkout that I
update after any checkin to make sure that a clean pull of the sources
from the server is still in a sane state. We could also setup some sort
of auto-builder somewhere (gcc and classpath have that. the gcc one is
pretty cool since it tries to extract the email addresses from the
ChangeLog files to see who might have caused the failure).

Cheers,

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]