Hi Matthew,
Le 04/08/2012 04:59, Matthew Brush a écrit :
Since some plugins share dependencies, is there some way to coordinate both the versions of the dependencies and the build system? For example if Debugger and MultiTerm both depend on LibVTE, to make sure they use compatible API versions and depend on the same version. I'm thinking it's not great to require LibFoo v0.01 for one plugin and LibFoo v0.02 for another, even if they (can) use common API (and probably do already).
I guess it's more of a build system question, is it realistic?
Common/interesting dependencies based on a quick scan of the `build` directory:
[...]
For most of the dependencies, I think the GEANY_CFLAGS/GEANY_LIBS would cover it (gtk, glib, gio(?), gmodule, gthread, etc.). For the others maybe there could be some tweaking of versions to at least make the dependency versions the same. I know for my two plugins (DevHelp and MultiTerm) the versions of the dependencies are not very much of a concern and I mostly copied existing plugins' .m4 files.
Just a few thoughts I had while mucking around with the build system.
I'm not sure I understand your concern. Dependencies should reflect what's needed for the package (here, the plugin) to build/run or whatever. Since all libraries either keep backward API compatibility or make it possible to have both version at the same time [1] (either by changing name/including major version in it or by following common rules about versionning (see Libtool Versionning in your favorite manual)), I don't see chat can be the problem.
If you have library X in version 64, and have plugin A depend on version
= 21 and plugin B on version >= 50, both are happy. If you had version
42 of the library, only plugin A would have built. Nobody expects you to install version 21 AND version 50 of the library.
So honestly I don't see what your concern is. If plugin A can work with version 21 of the library X but plugin B uses new stuff that is only available since version 50, I don't see why we should either prevent plugin A to accept version < 50 or plugin B to use that new API.
For GTK2 or GLib, we might want to ask authors whether they can stick to a particular version, e.g. to the same version Geany requires so hopefully one could always have the plugins if they have Geany -- unless they depend on another library. But IMO that's a special case for these two libraries Geany also uses, and I don't even think that we should really prevent one to depend on a newer version of GTK2 if they want a feature from it.
So... maybe I got your point wrong, but I don't think it's any kind of a problem to have different dependencies from one plugin to another -- actually, I think each plugin should set it dependencies to exactly what it needs: nothing less (of course), and nothing more.
Regards, Colomban
[1] or you just have to kill their author and/or your distributor... :(