harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Petrenko" <alexey.a.petre...@gmail.com>
Subject Re: [general] JPackage - new opportunity for Harmony?
Date Fri, 16 Nov 2007 07:47:46 GMT
2007/11/16, Mark Hindess <mark.hindess@googlemail.com>:
>
> 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).
Yes! This would be really good!

SY, Alexey

Mime
View raw message