After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 361899 - Building glib-java on OpenSolaris
Building glib-java on OpenSolaris
Status: RESOLVED FIXED
Product: java-gnome
Classification: Bindings
Component: Bindings Core
mainline
Other opensolaris
: Normal normal
: ---
Assigned To: java-gnome bindings maintainers
java-gnome bindings maintainers
Depends on: 360207
Blocks: 361653 361724 361883 361894 361896
 
 
Reported: 2006-10-13 10:01 UTC by John Rice
Modified: 2007-01-05 00:59 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16


Attachments
Patches for building glib-java on OpenSolaris (4.76 KB, patch)
2006-10-13 10:02 UTC, John Rice
committed Details | Review

Description John Rice 2006-10-13 10:01:34 UTC
This is a set of buildsystem patches to allow glib-java to be built on OpenSolaris nevada build48 and above [currently this build uses Gnome 2.14, but will be bumped to Gnome 2.16 shortly].

Changes for the following:
1. Get src building: remove compiler warning on OpenSolaris.
2. Need glib-java-uninstalled.pc.in for common routines for Java-GNOME
bindings, Not installed. Needed when building meta/uber packages.
3. Configure --with_javadir is meant to be a supported configure option to tell the build where to put generated jar files, but had some hard coded path bugs and was not being picked up in generated .pc file.
4. Generating Javadoc on OpenSolaris - problem with use of "find -mindep". Not supported on this OS, simple generic workaround added. Also added missing classpath to remove build errors.
5. Need to change where doc base dir is set in the build, as we wanted to put it in a different location on OpenSolaris. Currently defaulting to ${datadir/doc}. Added configure option --with_docbasedir to support this.
6. Need to change where macro base dir is set in the build, as we wanted to put it in a different location on OpenSolaris. Currently defaulting to ${datadir/doc}. Added configure option --with_macrobasedir to support this.

Both docbasedir and macrobasedir support requires the glib macro jg_common.m4 Patch 74620 Bug 360207
Comment 1 John Rice 2006-10-13 10:02:25 UTC
Created attachment 74624 [details] [review]
Patches for building glib-java on OpenSolaris
Comment 2 Andrew Cowie 2006-10-15 08:56:14 UTC
If a bug (this one) depends on a patch in another (360207) please use the "depends on" field in the bug to show this.

AfC
Comment 3 Andrew Cowie 2006-10-15 09:20:56 UTC
I'm not sure if I buy "Need glib-java-uninstalled.pc.in for common routines for java-gnome bindings, Not installed. Needed when building meta/uber packages." as I'm not sure what an uber package is.

As I've seen it used, a "meta" package is simply one that depends on others thus pulling in dependencies and is generally sufficient for all sorts of purposes. If "uber" package means somehow lobbing all the sources together to ship them as one blob, that's very unusual (and generally frowned upon for the reason that it gets users out of sync with developers [or, in our parlance, developers out of sync with hackers] which tends to cause problems when people ask for help) - though what you do on your systems is your business.

[I would note that the issue of library proliferation and the attendant ridiculous administrative burden is one of the issues I expect to see us address in java-gnome 4.0, assuming it is funded]

Back to the patches here and in the related bugs, I am moderately unenthusiastic about having a -uninstalled.pc file in every library we ship. The effort of adding it is minimal, of course, but the potential for bugs to creep in because of yet *another* metadata file that needs maintaining is not to be trivialized.

You sure you can't do without this extra .pc file?

I'm pretty much prepared to go ahead with this whole series of patches, but I'd appreciate if you'd comment on this issue first.

AfC
Comment 4 John Rice 2006-10-16 08:19:42 UTC
Andrew I understand your concerns about yet another metadata file to maintain so let me explain.

The Gnome we ship with Solaris is built on the SVR4 packaging system via a series of spec files, very similar in essence to rpms. One of the core packages that is created is the SUNWgnome-base-libs. This is an uber package used to pull together a series of different gnome libraries into a logical grouping for ease of maintenance and consistency for each major Gnome release. The uber package is a spec file itself and expresses the appropriate dependencies for each of the sub packages, so it does help express the notion of a coherent release [all base libs for Java Gnome release 2.14 are grouped into this one package].

So when I submitted the case for Java-Gnome in Solaris using the communities packaging structure, the ARC guys [Sun's architectural review folks] got back to me and said they would like me to follow the same uber package convention for the reasons above. So this is why I need the uninstalled.pc file, to allow the uber spec file to build the base libs for the uber package in sequence and allow the various sub packages to find the jar dependencies in the temporary build tree.
Comment 5 Andrew Cowie 2006-10-17 05:50:44 UTC
Fair enough.

[We'll need to have a rather careful conversation about packaging in the future. As I've quipped elsewhere, both the complexity of the autotools (largely unnecessary for our project) and the ridiculous proliferation of our family of libraries (due to the one package per thing wrapped approach at source level) means that this is all a bit cumbersome and quite a ripe target for doing *much* better. That said, I don't want to deliberately piss anyone off, but I'm sure we can come up with something a bit more sensible in the 4.0 effort]

Applying.

AfC
Comment 6 John Rice 2006-10-17 08:45:08 UTC
Yep - agree Andrew we can definitley simplify things. Having patched all the various libs in the last few weeks I feel your pain ;)