2007/11/16, Mark Hindess <[EMAIL PROTECTED]>: > > On 15 November 2007 at 23:33, Gregory Shimansky <[EMAIL PROTECTED]> wrote: > > Mark Hindess wrote: > > > On 14 November 2007 at 19:57, "Alexey Petrenko" > > > <[EMAIL PROTECTED]> 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
