Re: [java-gnome-hackers] Libraries vs Packaging (1): Linkage

[Philipp H. <phi...@gm...>]

Hello again,

I sort of implemented the changes I suggested in the post from
earlier. It allows to optionally compile the library with different
modules. Please try it and let me know what you think:

$ bzr co --lightweight lp:~binwiederhier/java-gnome/modules java-gnome-modules
$ cd java-gnome-modules
$ ./configure --with-module=appindicator-0.1
$ make
$ ldd tmp/*.so
--> Appindicator included

Changes I made:
- moved the directory "src/defs" to "src/defs/core"
- moved the directory "src/bindings" to "src/bindings/core"
- added one directory for each module:
  1. "src/defs/appindicator-0.1" and "src/bindings/appindicator-0.1"
  2. "src/defs/indicate-gtk" and "src/bindings/indicate-gtk" (*** see below)
- adjusted all scripts (mainly configure, faster, Makefile and
BindingsGenerator) to support more than one "defs" and "bindings"
folder

Note: when you recompile, make sure to delete the tmp-folder since it
might contain "modules" that are not defined in the --with-module
thing arguments anymore. "make clean" is not enough here.

What do you think? It's not a dynamic loader, but it's a start and it
doesn't break the old stuff...

Cheers,
Philipp

*** On Natty, use 'indicate-gtk-0.5' instead. It didn't compile for me
though. I think because of the major version jump ...

On Tue, May 31, 2011 at 10:40 PM, Philipp Heckel
<phi...@gm...> wrote:
> Hallo everyone,
>
> First of all: thank you for a great library. I wouldn't know what to
> do without it :-)
>
> I am referring to the issue of "optional dependencies" discussed in
> [1]: I can definitely understand the discussed problems: many
> developers probably only use a fraction of the built-in functionality.
> Reducing dependencies and having optional dependencies is certainly a
> must in big projects like this. However, in my opinion, an issue like
> this should not stand in the way of making progress and including new
> functionalities: Francisco implemented support for App Indicators over
> a year ago [2] and even though is works like a charm, it is still not
> in the library.
>
> In the long run, I would love a dynamic loader that only allows the
> use of classes for which the native libraries are available. For
> example, if libappindicate is present, an application may use the
> corresponding Java classes. If not, an exception is thrown.
>
> However, to avoid getting stuck in an endless discussion about how to
> implement this, I'd suggest to adjust the configure script to allow
> choosing libraries at build-time. This is exactly what Serkan
> suggested (2011-05-05 07:17). Something like: ./configure
> --with-module=libappindicator
>
> That way, if the "default version" in the distros' repositories is not
> built with the desired functionality, one could check out the source
> of the current stable version (4.0.19) and simply re-compile it
> --with-module=...
>
> What do you think of that?
>
> Cheers
> Philipp
>
> [1] https://sourceforge.net/mailarchive/message.php?msg_id=27435400
> [2] https://sourceforge.net/mailarchive/message.php?msg_id=25397649
>