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... :( _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel