From: Archie Cobbs (archie@whistle.com)
Date: Wed Sep 09 1998 - 20:07:15 EDT
Godmar Back writes:
> > 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.
Ah, that's something I haven't tried before... thanks!
Now I understand the implicit assumptions you're referring to.
However, does it make sense to *not* do it this way? That is,
if your purpose is to regenerate derived files so you can
(a) Check them in, or
(b) Create a tarball
then you would want to do this inside the source tree. The main
motivation for "make derived-files" is for a developer to update
all of the *source* files that are derived from other source files.
But of course, it doesn't hurt to have "make derived-files" respect
whatever object directory you're using, because if you want to stay
in the source tree the effect is the same (so I'm agreeing with you :-)
> 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.
I think it's even weirder that the source tree contains derived files
at all! Just to reiterate my personal opinion:
- The CVS repository should contain *no* derived files at all.
- The kaffe-snap.tgz tarball should contain only those derived files
necessary to build and install kaffe on a system that has no existing
Java support (eg, Klasses.jar).
- There should be a script that runs every night at Transvirtual
which checks out the latest source into an environment with a
reliable Java VM, C and Java compilers installed already, builds
kaffe, installs it, regenerates the derived files (as many times
as necessary to achieve confidence, etc), and then does a "make
distclean" and tarballs up the result, which then becomes the
next kaffe-snap.tgz.
> > > 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
I did, because the file is completely automatically generated. I
didn't want to "cvs remove" anything though.. I guess I was trying
to be consistent with the policy of leaving derived files checked in,
but this file is really different because everybody has "sed" already.
We can simply remove it and tweak the makefile to make sure
it gets regenerated before a make depend or make all.
> > 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.
OK, so that's an optimization... :-)
> > 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.
Depends on what you're trying to achieve I guess. Yes that makes more
sense, so bugs don't "propagate"..
> > - 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.
Hmm.. why would you want to do that?
-Archie
___________________________________________________________________________
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:56:56 EDT