Re: error during nightly classpath builds

[Michael Koch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Samstag, 22. Mai 2004 06:06 schrieb 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.

Thanks.

> 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?

Because it may find a working version of jikes or kjc that works.

> 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).

I tested this here and configure broke with:

checking for gcj... /usr/bin/gcj
checking gcj version... 1
configure: WARNING: 3.3.320040401): gcj 3.6 or higher required
checking for /home/mkoch/local/jikes/bin/jikes... no
checking for kJC... no
configure: cannot find javac, try --with-gcj, --with-jikes, or 
- --with-kjc

> 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

I wonder what you did to get this.

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

Yes, it should fail here. We need to look into it.

> 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?

Good idea.

> 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.

I'm all for it. Its so bad. I fall into this from time to time too, 
e.g. yesterday with the broken kjc script from kaffe.


Michael
- -- 
Homepage: http://www.worldforge.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFArv1rWSOgCCdjSDsRAs+vAKCGmAAhwAvs7tsF+SvtJ2NWrOd4nACgkBhf
yFjibNrDrTxZ457gIc/Lgks=
=p9mG
-----END PGP SIGNATURE-----