Re: [CVS] commit

Date view Thread view Subject view Author view

From: Archie Cobbs (archie@whistle.com)
Date: Wed Sep 09 1998 - 14:54:43 EDT


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.

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

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.

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

It wasn't my intention to avoid having to do these steps... but
I guess I could have pointed that out more explicitly.. ie, you
have to follow the above sequence. Perhaps we can add a new target
to the top level makefile...

  regen: depend all install derived-files all install derived-files

But beyond this I don't know if it's worth the trouble adding a bunch
more makefile logic.

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

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)

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

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

 - Makefile:

     - add new target "regen":

        regen: depend all derived-files all derived-files

Comments?

-Archie

___________________________________________________________________________
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:56:56 EDT