Re: error during nightly classpath builds

[Steven Augart]

Steven Augart wrote:
[....]
>  Am also looking at the configure problem; we have some version test 
> code in acinclude.m4 and it has some clear bugs
[....]
> I'll see if I can fix it tonight. 
[....]

I have fixed the version test code and submitted a patch to the 
commit-classpath list.

However, it is the case that, if there's a version mismatch, we will 
just print a warning and go on configuring.  (The version test macro 
had this behaviour in the previous version; I am not comfortable 
changing it without discussion here.):

  checking gcj version... 1
  configure: WARNING: 3.2.220030222 (Red Hat Linux 3.2.2-5): gcj 3.3 
or higher required

Given that configure spits out 348 lines of text while it's running, 
I'm concerned that the user might miss the one line that says 
WARNING:.  Is there any reason why the macro doesn't call AC_FATAL 
instead of just AC_WARNING?

It led to the very weird result on my system that the configuration 
appeared to finish successfully (if one missed the warning message 
early on).

Apparently, the configuration completes with GCJ set to the empty 
string, and subsequently used.  The actual build starts like this:
> Making all in lib
> make[1]: Entering directory `/home/augart/JikesRVM/ClasspathCVS/classpath/lib'
> top_builddir=.. /bin/sh ./gen-classlist.sh standard
> bootclasspath '' -classpath ..:../external/jaxp/source:../vm/current:.: -C -d . 
> @classes
> make[1]: bootclasspath: Command not found
> make[1]: [compile-classes] Error 127 (ignored)
> touch compile-classes
> if test "/usr/bin/zip" != ""; then /usr/bin/zip -r -D glibj.zip gnu java javax org 
> > /dev/null; fi

It then goes ahead and builds all of the C stuff.

This has gone from bad to worse.  Now that we've mis-configured the 
system, we go ahead and ignore the build error that would tip the user 
off.  Can a new user be blamed for assuming that the message was benign?

We then goes ahead and creates a ZIP file that just contains a few 
resources (the .properties files) and no classes.  When that ZIP file 
fails to work to build or run someone's VM, it will look like a VM 
bug, since Classpath was presumably built correctly, even though it 
wasn't.

If we find an out-of-date gcj in the normal process of searching for a 
java source-to-bytecode compiler, I am all in favor of a warning 
message, followed by a search for the Jikes compiler.  But if we find 
an out-of-date gcj when the user has explicitly configured the system 
with something like --with-gcj=/usr/bin/gcj , I think the configure 
process should die immediately.  It certainly shouldn't create a 
configuration that will silently build a non-working version of Classpath!

Is there any disagreement with this point of view?

The biggest single source of problems for new Jikes RVM users has been 
due to failures to build Classpath.  I have a better idea now how such 
problems arise.  If we fail, let's fail immediately and spectacularly. 
 Then people will know what the problem is.

In the mean time, I'm probably going to add new sanity checks to Jikes 
RVM's build process, so that we recognize this kind of bogus Classpath 
build (a glibj.zip that doesn't contain any .class files).  The build 
process will abort with a useful diagnostic message.
--
Steven Augart

Jikes RVM, a free, open source, Virtual Machine:
http://oss.software.ibm.com/jikesrvm