[kaffe] Re: Updating Jessie
Dalibor Topic
robilad at kaffe.org
Mon Dec 1 10:13:02 PST 2003
Hi Casey,
Casey Marshall wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>>>>>>"Dalibor" == Dalibor Topic <robilad at kaffe.org> writes:
>
>
> Dalibor> The next step is to update Jessie to 0.9.5. I've tried to do
> Dalibor> that by re-merging the source code in, but that fails to
> Dalibor> build unless kaffe has been built with GNU Crypto, since it
> Dalibor> depends on some classes from gnu.crypto that are not in
> Dalibor> kaffe's CVS [1].
>
> I suggest re-syncing the javax.* packages that come with Jessie, and
> omitting the org.metastatic.* packages. These parts are completely
> independent, and the former has no dependencies on any external
> software. Plus I don't see any reason why these classes will change
> drastically; they are quite abstract and simple, and I think they are
> mostly correct as-is. The CVS sources for these are what you should
> use, by the way, as a few bugs are fixed there.
thanks, I'll check in the current jessie javax.* from CVS and remove the
org.metastatic classes again from the CVS.
> It was looking as though the javax packages would become a part of
> Classpath, and that Jessie would just comprise the org.metastatic
> packages, but I haven't heard any definitive answer yet.
Mark Wielaard is the one to talk to.
> Dalibor> So I'd propose removing old Jessie sources from kaffe's CVS,
> Dalibor> and using a --with-jessie argument like for GNU
> Dalibor> Crypto. Casey, maybe you could take a look at the
> Dalibor> gnu-crypto.m4 macro from Raif in kaffe's CVS, and adapt it
> Dalibor> for Jessie? It would make intergration of jessie during the
> Dalibor> build process simpler into other VMs as well.
>
> I will take a look.
Thanks!
> Dalibor> The only trouble with those is that you need the jar files to
> Dalibor> be built already before you can build kaffe with them. That
> Dalibor> means someone building kaffe with jessie without access to
> Dalibor> the jar files would first have to build kaffe, then build GNU
> Dalibor> Crypto with kaffe, then rebuild kaffe with gnu crypto, then
> Dalibor> build jessie with kaffe with gnu crypto, and then rebuild
> Dalibor> kaffe with gnu crypto and jessie. Sounds inefficient ;)
>
> Is it possible to add the source trees from these projects into some
> 'upstream' directory of javalib, and compile them along with
> everything else, based on config flags?
That could be the --with-upstream-project-name-source=PATH options. It
would mean hacking a small m4 macro for each --with-source option, that
sets USES_PROJECT_NAME_SOURCE and PROJECT_NAME_SOURCE_PATH. We could add
an upstream dir in libraries/javalib, with its own directories and
wrapper scripts for compiler invocation for each upstream project.
Basically, I think it should be enough to do a
cd $PROJECT_NAME_SOURCE_PATH
rm ($build_dir)/all-project.files
touch ($build_dir)/all-project.files
for i in src_dir1 scr_dir2 ... do
find $i -name "*.java" >> $(build_dir)/all-project.files ;
done
$(top_build_dir)/libraries/javalib/rebuildLib
@$(build_dir)/all-project.files
> And by 'possible' I mean 'not a complete pain in the ass'.
Ant ;)
Seriously though, the hard bit above is collecting all the names of java
files to compile. If we check that information in for each upstream
package, and regenerate it when developers/autogen.sh is invoked, I
don't see a problem.
> Or: is there any plan to add an extension directory to Kaffe?
> Analogous to the ext/ directory in other JREs?
That's what the change I proposed in kaffe.in in my last e-mail was
about, without explicitely using an ext directory. It relied in
install-jar to copy the jar to the apropriat elocation, and would pick
up all the jars in the directory it considers O.K.
cheers,
dalibor topic
More information about the kaffe
mailing list