Re: [java-gnome-hackers] Libraries vs Packaging (1): Linkage
Brought to you by:
afcowie
From: Andrew C. <an...@op...> - 2011-06-02 00:49:23
|
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/ |