From: Godmar Back (gback@cs.utah.edu)
Date: Wed Sep 09 1998 - 16:20:08 EDT
Hi Archie,
>
> Godmar Back writes:
> > Archie, the derived-files target assumes that you configure in
> > your source tree. I put in fixes to two files, could you fix the
> > rest? Here's what I noticed:
>
> I'm not sure I understand what you mean. If you don't configure
> in your source tree, you can't say "make" at all because there are
> no Makefiles.
Okay, I think we're misunderstanding each other here.
configure distinguishes between the source tree and the object tree.
The object tree is determined by where you invoke configure.
If you "configure in your source tree", then you choose object and
source tree to be the same. (As in ./configure)
Many people don't do that, for instance, because
a) they don't want to mix object and source files
b) they have different object trees with different configuration
options (static/dynamic, intrp/jit) that share the same source tree.
c) they have different objects tree for different architectures
that share the same source tree.
d) they keep their object tree on a filesystem that is not filesaved.
Properly written .in files never assume anything about where
configure is invoked.
To try it out, create a directory "obj", cd into it and type
$kaffesrcpath/configure. (Or $kaffesrcpath/configure --prefix=)
I think it's already a bit weird that we have a make target that
updates stuff in the source tree, but so be it.
>
> > The external_wrappers.h stuff is inconsistent. For instance,
> > in native/Makefile.in it's a derived file, in awt/Makefile.in it's
> > part of the normal build. Independent of that, it's broken.
> > I think it should be part of the normal build. Note that it also
> > must added to the depend target. Once it's part of the normal build,
> > it can be removed from the CVS directory.
>
> I just preserved what was there before. That is, it was already
> inconsistent before I added the "derived-files" targets.
I see.
I thought you added the external_wrappers.h targets in native/Makefile.in
>
> However, I completely agree: if it's a derived file, and you don't
> need to have already built kaffe it in order to derive it (unlink
> Klasses.jar), then it should be removed from the repository and
> generated on the fly during the normal build. I'll fix this when
> I get a chance.
That would be great.
>
> > The recreation of java_lang_Thread.h must be done *after* the
> > libraries after recompiled. (The current target seems to be doing
> > it before, which uses an old Klasses.jar)
>
> Right.. to be correct, one should do this sequence when regenerating
> the derived files:
>
> $ ./configure
> $ make depend all install
> $ make derived-files
> $ make all install
> $ make derived-files
> $ make distclean
> $ cvs checkin
>
> [ It's kindof like when you port gcc to a new platform.. you have to
> compile it (with the native compiler), then you have to recompile
> it (using the new gcc itself), then recompile it again (using itself
> again).. and compare the results of the second and third compilations,
> which should be identical. They might not be if the native compiler
> has bugs in it. ]
I agree.
>
> > To recompile the class libraries, configure should check for an
> > installed java compiler: preferably kaffe, but any other should do.
> > We need a test in configure for that.
>
> I prefer the gcc approach.. kaffe should only rely on outside tools
> to bootstrap itself -- and since we include pizza.jar and Klasses.jar
> in the distribution, it doesn't even need to do that.
It's no different than the gcc approach, in my mind.
gcc relies on the existence of a C compiler to bootstrap itself,
this may or may not be gcc.
Kaffe relies on the existence of a Java compiler to bootstrap
itself, this may or may not be kaffe's javac (pizza).
>
> You still have to do "make derived-files" twice: once to generate
> the new Klasses.jar, and again to generate the headers (which of
> course depend on Klasses.jar)
Why?
If you arrange make derived-files such that it will first
build the new Klasses.jar, and then have kaffeh use the new Klasses.jar
(or maybe even just the .class files), you should be fine.
You only need to do make derived-files twice if you want to be sure
that the kaffe you built can recompile its own class libraries properly.
>
> Hmm.. this all gets confusing... here are some proposed changes to
> keep the discussion going. These fall into two categories: (a) making
> sure that the "local" versions of Klasses.jar and pizza.jar are used
> for generating derived files, and (b) adding new dependencies.
>
> - libraries/javalib/Makefile:
>
> - before calling the rebuildLib script, define $JAVA in
> the environment to be:
>
> ../../kaffe/kaffevm/Kaffe -classpath $(CLASSFILE):pizza.jar
>
No, that doesn't work.
rebuildLib must use an already existing Java compiler/JVM, not the
one we just built.
> - make Klasses.jar depend on */*/*.java (what's the most portable
> way to do this in a makefile?)
>
> - include/Makefile:
>
> - add dependence of derived files on ../libraries/javalib/Klasses.jar
Not sure we need this.
Always recreating these few header files should be easy.
> - already fixed to use the "local" kaffeh instead of installed one
>
> - libraries/clib/*/Makefile:
>
> - remove "external_wrappers.h" where appropriate and generate
> them automatically on the fly.
> - make sure they get generated before "make depend" runs.
Yes.
>
> - Makefile:
>
> - add new target "regen":
>
> regen: depend all derived-files all derived-files
>
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:56:56 EDT