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

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

On Wed, 2011-06-01 at 17:58 +0200, Philipp Heckel wrote:

> As you might have seen, I've implemented some changes...

So if you only need this for your direct use to slim the library down
for your situation, then by all means, go for it, and I'm glad its
working out.

> 
> Most importantly: my adjustments do NOT change the default behavior. So
> the distro versions will not be affected by this.
> 

Well, the moment one distro does --enable-something and other distro
does --disable-soemthing in their packages then we have an inconsistent
API for developers.

And (this is the part that you may not be seeing directly) that's the
part we, upstream, get blamed for. A developer doesn't care that the
"fault" is two different distros doing things differently. They just
know that java-gnome doesn't work. That's a serious piss off for them,
and it makes it very difficult for us to support users. Common problem
in Open Source, to be sure, but in our little corner of it we've avoided
it thus far.

Anyway, you get that. I just wanted to be clear that I'm not trying to
make life difficult for you on purpose. We just need to figure out the
experience we want for users of the library, then the design and
engineering that supports that.

>
> I'd appreciate it if you could take a look at it and tell me whether you
> might consider including this in the trunk.
> 

> > - added one directory for each module:

So that's an obvious one, now that you say it. Good call.

My thinking about this has come from the other side. My guess was that
the thing to do would be to put an individual loadNativeLibrary() call
in each package's Plumbing class's static { ... } block, rather than the
single all-encompassing master one down in
org.freedesktop.bindings.Plumbing's.

That would mean that the only libMODULENAMEjni.so that get loaded would
be those corresponding to modules you actually use as a developer, which
corresponds to the lazy loading of Java classes on the JVM side. Good.

It means more .so shared libraries. Lots more. Some people tell me
that's bad. Other people tell me not to worry about it.

So I was thinking about our Java package space, but a better level would
presumably be pkg-config space.

so,

src/defs/gtk-3.0/GtkButton.defs 

sure maybe.

> > - moved the directory "src/bindings" to "src/bindings/core"

This worried me, though. Carrying your example further,

> > + src/bindings/indicate-gtk
> > + src/bindings/appindicator-0.1

and so on. There will be 15 or 20 of these, I'd guess. The catch is that
src/bindings/ is a source package root in Eclipse and in the build
system. It's bad enough right now that we have 

src/gnerator/
src/bindings/
tests/generator/
tests/bindings/
tests/screenshots/
tests/prototype/
doc/examples/

all being source packages. So we would need

src/bindings/MODULENAME/
tests/bindings/MODULENAME/

for each variation, I guess. That's not very tidy. Maybe we just do

src/MODULENAME
tests/MODULENAME

going forward, although that's still very messy for Eclipse. Hm.

Or maybe we don't do that at all, build all the sources regardless, and
deal with it at C compile / link time and/or at Plumbing's static
{...} . That would save smashing the Java side of the build system so
much, at the cost of greater complexity on the C side.

++

We're on the right track, discussing this. It's something we've avoided
until now in this project but it's time to figure it out. Lovely to have
your interest and involvement.

AfC
Sydney


P.S. I just checked out your branch, and discovered
ubuntu-appindicator.patch in the root directory. What is that? And then
worse I discovered that you had .so and .jar files added in your
history. Eeek. You don't version control build products and patches :/ I
see that you discovered your mistake, but we're not going to [ever] be
able to merge this branch because it mean bloating everyone's
repositories with this history. Also please fix `bzr whoami` before you
redo these commit(s).

Please join us in #java-gnome I'm sure someone will be happy to walk you
through using Bazaar. There's a trick with bzr merge and revert that can
compress this all into a single patch which might just be the thing.





-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management: enabling
successful deployment of mission critical information technology in
enterprises, worldwide.

http://www.operationaldynamics.com/