[kaffe] Re: [tritonus-user] Tritonus on kaffe
robilad at yahoo.com
Tue Dec 10 05:19:17 PST 2002
--- Patrick Tullmann <tullmann at cs.utah.edu> wrote:
> Hey Dalibor,
> I didn't realize Tritonus provided part of JDK1.4
> compatibility. I
> see why you're trying to get it into the tree. Any
> chance there is a
> simple hacky fix to kaffe's libtool to get it to
> link c++ correctly?
Maybe, I think I saw some patches in the libtool
mailing list archives from some Mandrake Linux guys.
You can try to merge it with what we have (1.4.3), if
On the other hand, if that means "supporting" our own
version of libtool, I'd rather not go there, but just
take stuff from the upstream CVS, and remerge when
some significant bug is fixed.
> Since I think we're going to get bitten whatever we
> do, I think we
> should probably be doing more to reduce the need for
> developers to
> re-build Makefiles and configure. For example, the
> change proposed a
> while ago to remove the list of java sources from
> the Makefiles would
> be a really good step. I can work on that a bit
> unless someone else
> already has it working...
I agree. Just because someone would like to test a
class or two from Classpath, they should not have to
go through the whole 'edit
developers/autogen.sh, reconfigure, compile, and wait
for a while until it's finished' procedure. I find
that quite time consuming when I'm merging in new
classes, given that each (configure; compile; test)
cycle takes about 10 minutes on my current development
machine. So please go ahead, and make it better.
That frustration was one of the reasons why I proposed
ant for the job a few months ago. I've changed my mind
since, as suporting ant would mean that we need to
pull in javax.xml into Klasses.jar.bootstrap, and all
other classes for XML support. That would turn
Klasses.jar.bootstrap into the big, cvs-unfriendly
thing that Klasses.jar was. I wouldn't want that.
Ant has one great feature, though: given a path of
directories in the build file (equivalent to the
makefile in make-terms) it finds all *.java files and
compiles them, without the developer having to spend
time maintaining a current list of classes.
So if you plan to work on it, some code that does the
find $PACKAGE-BATCH -name "*.java" > class-files
would be great.
the ">" is there because as the class library grows,
enumerating it is going to exceed the maximum command
line length on most systems. It does so on IRIX
already, which is one of the reasons why I have split
Klasses_jar_SRCS in libraries/javalib/Makefile.am .
The other is amount of memory required to build kaffe.
It's not very funny to watch the garbage collector
crawl through the swap space for a day. ;)
My idea would be to have package lists in a separate
file, say classlib.packagelist. The format could be
like that of bootstrap.classlist, with a small
addition to allow to specify multiple batches of
Having it separately, means being independant of auto*
tools for class library issues.
What do you think?
> I imagine doing something similar for the extensions
> library is a bit
> too much (since libtool has to do linking of the
> generated objects).
> Any other ideas? Anyone else find themselves
> developers/autogen too much?
I think I'll be migrating the java bits of the
extension library into the main library directory
eventually. Sometime next year, at the moment I'm busy
with javax.sound, and if we get that in, I'll be busy
fixing the damage the transition to latest auto* tools
would have done ;)
I don't know about the native libraries, but I assume
that the situation is similar. I think it would harder
to flexibilize the build process for native libraries,
because of libtool.
Maybe that would be a nice addition to configure.in:
regenerate Makefile.in & Makefile when a Makefile.am
file is younger than its heirs. Just-in-time
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
More information about the kaffe