Success with current CVS on MIPS SGI Irix 6.3

Archie Cobbs archie at
Wed Aug 26 12:56:44 PDT 1998

Lee Iverson writes:
> In message <199808261802.LAA22896 at> you write:
> > 
> > Seems like it would make more sense to remove Klasses.jar from
> > the repository altogther and have the nightly kaffe-snap script
> > rebuild it from the sources.
> > 
> > There are several similar but different states a source tree can
> > be in, including:
> > 
> >   1. Freshly checked out of the repository 
> >   2. Distribution-ready
> > 
> > #1 should contain no derived files like Klasses.jar. #2 should only
> > contain those derived files that are necessary (eg, Klasses.jar --
> > a user needs kaffe in order to rebuild it -> chicken and egg problem)
> Agreed.  But in the case of #1, the default 'make all' target *must*
> update all of these dependent files, which is definitely not being
> done now.
> That said, I still think that Klasses.jar should be in the CVS
> repository because of the impossibility of bootstrapping it without a
> pre-existing Java compiler.

That *seems* to make sense, but IMHO it really doesn't.

By that argument, pizza.jar should also be in the repository
(which it is already, yuk).

And continuing this logic, so should gcc, and libc, and ...

At some point you have to assume a minimum "build environment".

I'd claim it's safe to assume that 'javac' is part of this build
environment, because the people doing builds from the "repository
release" are developers (e.g., the Transvirtual script that runs
each night) and they have a JVM already installed.

Of course, kaffe "consumers" should start with the distribution
release (which includes Klasses.jar), as opposed to the repository

Admittedly, there is a potential chicken-and-egg situation, but it
would never normally come up. Besides, now you can always check
out an older version of the repository to resurrect Klasses.jar if
you get stuck somehow.


PS. At Whistle we solve this problem by creating build environments
within which all builds are done. Each build environment is literally
a complete FreeBSD disk image tar'd and gzip'd and stored away,
including compiler, libraries, etc. Build environments themselves
are created using fixed 'recipies' that start with a FreeBSD release
on a CDROM. So nothing 'derived' is stored in the CVS repository.
I'm not saying everyone should do it this way, but it's a lot cleaner
and avoids the kind of inconsistencies that the original email in
this thread was complaining about.

Archie Cobbs   *   Whistle Communications, Inc.  *

More information about the kaffe mailing list