Re: [java-gnome-hackers] optional dependencies (was Re: ...)

[Andrew C. <an...@op...>]

On Fri, 2010-05-28 at 15:03 +0200, Guillaume Mazoyer wrote:
> But they should absolutely not be required to build java-gnome or any
> kinds of programs (in C people use #ifdef things to know if the code
> should compile with appindicator/libindicate support).

Yeah. java-gnome isn't really very good at that right now, partly
because

a) Java the language isn't very good at that

        [and that's ok; no #ifdef is a feature, not a bug :). Actually,
        Java is very good at it - if you don't depend on it, you don't
        import it. But the code in scope needs to compile]

b) philosophically, I didn't want to maintain a project where people
wouldn't know whether what they needed would be there or not.

        [There's nothing worse than you installing something only to
        discover (eg) your Cairo doesn't have PDF support. "Like, what
        the fuck, man?" with my best 70s California surfer dude
        accent :). We just depend on Cairo, and expect it to work.
        People should be able to depend on java-gnome, and know what
        they're getting]
        
c) java-gnome depends on GNOME; so, if you've got a Desktop installed
you by definition have all the prerequisites.

        [Done. No fuss, no muss, and makes sense given the limited time
        we all have to spend on things like this. It's also why I've
        kept it 1 package and not 9]


> I was stuck on "they should be optional not
> required".

d) we haven't implemented out the infrastructure and mechanisms for
optionally depending on individual libraries.

This is where it gets interesting. This *IS* something we have been
thinking about for a long time and have a fairly good idea of what we
need to do to support it.

For example, I'd rather like to see us have a webkit-gtk binding, and
James even worked on one a bit, but (especially a few years ago) it was
completely unreasonable to expect a normal user of release or 'mainline'
would have it available.

But it's really hard. The build system assumes all the sources will
compile.

        [What an amazing thought!]

So if we put in code that depends on things $you don't have on your
system, then boom java-gnome won't build.

So we'd need to change that. Fair bit of work. Also, top level configure
would also have to be taught what to do when it looks for something and
doesn't find it. Another big piece of work, though that's more doable.

Then we need to build the library such that it only links against the
things you actually have (so it completes the build, hey). That's a bit
more engineering. Getting trickier.

The usual approach to these problems is to make many libraries instead
of one. In java-gnome it wouldn't be *too* hard to load a bunch of
lib{glib,gtk,webkitgtk,...}jni-4.0.so; presumably we'd just do it one
loadLibrary() per module in the Plumbing class. So we'd need to arrange
that, then arrange to link the individual .so files instead of one big
one. That is all doable, but it's a LOT of work.

++

My take on it as maintainer is that we're still better off having just
one top level .jar file (which for historical reasons is called gtk.jar)
because Java only loads what you import and it doesn't matter a whit if
*EVERYTHING* is in that .jar, and it's a pain in the ass having to add >
1 to your IDE, run scripts, etc.

If the library itself then quietly internally then loads 10 - 15 .so
files rather than the 1 .so file it's loading now, then I guess that'd
be ok.

        [purists would complain about the cost of all the extra dynamic
        libraries, but I'm not so sure that in a land of Java on top of
        GTK that # of .so files is our biggest worry. Still, right now
        we have 1 and that's acceptable in anyone's books]

Since supporting experimental or obscure (indicator is "obscure in the
sense that no one but Ubuntu users will ever have it) would be really
excellent, it'd be worth doing the work to implement it.

It'll take hacking on configure, the build system, the Plumbing classes,
and knowing a lot about how linking works ... essentially, everything
there is to know about java-gnome :)

Big piece of work, but if we want to go there, I'm happy to help.

AfC
Sydney