harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [general] JPackage - new opportunity for Harmony?
Date Thu, 15 Nov 2007 21:38:11 GMT

On 15 November 2007 at 23:33, Gregory Shimansky <gshimansky@apache.org> wrote:
> Mark Hindess wrote:
> > On 14 November 2007 at 19:57, "Alexey Petrenko"
> > <alexey.a.petrenko@gmail.com> wrote:
> >> One of the Tomcat developers has pointed me to JPackage project[1].
> >> This project is distributing a rather big number of Java based
> >> projects for Linux in common way.  It also distributes JDKs. Now they
> >> have only Sun JDK in their list.
> >>
> >> I think it would be good for Harmony to try to participate in this
> >> project.
> >>
> >> I've wrote a letter to JPackage discussion list and has received few
> >> favorable responses.
> > 
> > Excellent.
> > 
> >> So we probably should create JPackage compatible rpm of Harmony and
> >> suggest it for inclusion.
> >>
> >> The good thing that we can demonstrate all the benefits of Harmony's
> >> modularity by creating a set of rpms and let the user choose which
> >> parts of Harmony he really needs.
> >>
> >> Not so good thing is that we need significant changes to Harmony's
> >> build system to be fully compatible with building Harmony from source
> >> RPM. Which is probably not a requirement for JPackage but a good form
> >> for Linux community.
> > 
> > I assume you mean the requirements not to include external
> > libraries/jars?  I've been thinking about this problem a little and
> > am keen to move things forward.
> >
> > I added the hy.local.zlib option to remove one such issue but there
> > are many more in terms of jars/libs/fonts/etc that still need to be
> > addressed.  I don't really like the hy.local.zlib option and think
> > that really we need to (re)design the way we handle dependencies
> > consistently across classlib/jdktools/drlvm with support for local/
> > system and remote/downloaded dependencies.  (The recent icu issue is
> > a good example of the problems that should be avoided by having an
> > accurate, implicit, consistent dependency implementation.)
>
> I've argued with Geir since the beginning that I'd like to see
> Harmony using dependencies from the installed distros as must as
> it is possible while Geir insisted that we link statically when we
> can. Things played in the favor of my POV a bit when it appeared that
> on x86_64 linking statically with jpeg, png and lcms simply doesn't
> work as these packages built statically by distros are not built as
> relocatable code, and we don't want to distribute our own versions of
> jpeg, png and lcms binaries.

Of course, we do for windows so we could distribute -fpic versions for 
the other platforms too.  But I agree we don't want to.

> Geir however has got a point since only a binary JRE is certified as a 
> Java(TM). For example Sun distributes its JRE with the above libraries 
> linked statically.

Geir did have a point but I never understood why we needed static
versions of jpeg, lcms, and png but not X11, Xft, Xau, Xdmcp,
fontconfig, freetype, Xrender, expat, libc, etc.  Particularly when you
consider that the API for jpeg has been stable for years and many of the
others have not.

I assume that we'd will need to specify the environment certified binary
JREs are certified on so I don't see how adding a few more things to the
description of the environment is a big problem.

> The list of Harmony dependencies goes much farther than just graphical
> libraries. And handling them should be more flexible than it is done
> currently. Why do you not like hy.local.zlib? Something like that
> I've been thinking about, making more packages to be taken from local
> installation to allow tighter integration with packages that distros
> create.

I don't like it because I think this detail should be hidden by whatever
abstraction we create to handle dependencies.  For example, I think we
should just query the dependency abstraction in much the same way that
other systems query pkg-config.  For example, on my machine I can do:

  pkg-config --cflags libpng

and get the answer:

  -I/usr/include/libpng12  

and:

  pkg-config --libs libpng

and get the answer:

  -lpng12  

If I so wished (I don't it is a terrible idea) then I could modify the
configuration so that the answer for --libs was /usr/lib/libpng.a and
everything I built from then on would use the static library instead.
But the builds don't need to care about these detail.

At the moment, I think extending hy.local.* to cover other dependencies
will start to get ugly pretty quickly.

Having said that, zlib is a bit of an odd one since we also change the
name (and explicitly load it in drlvm) so perhaps this one is necessary.

Incidentally, I'd also like to push the dependency information down to
the modules.  At the moment, if you run:

  ant -Dbuild.module=luni build-java

I think the build still looks up (checks at the moment) libpng/jpeg/lcms
headers etc.  This really should be handled by the awt module (and IIRC
imageio module for libjpeg).  I like the idea of having dependencies
specified within the modules (just as we do in the OSGI headers of the
MANIFESTs for java code).

Regards,
 Mark.



Mime
View raw message