Re: [Geany-devel] Geany-Plugins Dependency Consolidation
Am 06.08.2012 03:38, schrieb Lex Trotman: > On 6 August 2012 05:35, Matthew Brush wrote: >> On 12-08-05 07:57 AM, Frank Lanitz wrote: >>> >>> On Sun, 5 Aug 2012 16:55:07 +0200 >>> Frank Lanitz wrote: >>> > For a list of the dependencies, you can look through the `build` > directory's .m4 files and manually extract them (like I did for some > of the shared ones previously). The ones with the highest versions > will be the "minimum version required" to build geany-plugins (as a > whole). Maybe building a script doing this would be a good idea. >>> >>> >>> Having checked a couple of them I found it will be hard as they differ >>> in way defining the dependencies... >>> >> >> Yep and most don't specify their "shared" dependencies (GTK, GLIB, etc.) >> explicitly but assume that if you have the Geany, you have what they need. > > Agree with you that that is bad, they should be specified so that > users can be sure that the plugin dev meant "any version will do" > rather than that they just forgot to specify it :) ACK. Cheers, Frank ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins Dependency Consolidation
On 6 August 2012 05:35, Matthew Brush wrote: > On 12-08-05 07:57 AM, Frank Lanitz wrote: >> >> On Sun, 5 Aug 2012 16:55:07 +0200 >> Frank Lanitz wrote: >> For a list of the dependencies, you can look through the `build` directory's .m4 files and manually extract them (like I did for some of the shared ones previously). The ones with the highest versions will be the "minimum version required" to build geany-plugins (as a whole). >>> >>> >>> Maybe building a script doing this would be a good idea. >> >> >> Having checked a couple of them I found it will be hard as they differ >> in way defining the dependencies... >> > > Yep and most don't specify their "shared" dependencies (GTK, GLIB, etc.) > explicitly but assume that if you have the Geany, you have what they need. Agree with you that that is bad, they should be specified so that users can be sure that the plugin dev meant "any version will do" rather than that they just forgot to specify it :) Cheers Lex > > > Cheers, > Matthew Brush > ___ > Geany-devel mailing list > Geany-devel@uvena.de > https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins Dependency Consolidation
On 12-08-05 07:57 AM, Frank Lanitz wrote: On Sun, 5 Aug 2012 16:55:07 +0200 Frank Lanitz wrote: For a list of the dependencies, you can look through the `build` directory's .m4 files and manually extract them (like I did for some of the shared ones previously). The ones with the highest versions will be the "minimum version required" to build geany-plugins (as a whole). Maybe building a script doing this would be a good idea. Having checked a couple of them I found it will be hard as they differ in way defining the dependencies... Yep and most don't specify their "shared" dependencies (GTK, GLIB, etc.) explicitly but assume that if you have the Geany, you have what they need. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins Dependency Consolidation
On Sun, 5 Aug 2012 16:55:07 +0200 Frank Lanitz wrote: > > For a list of the dependencies, you can look through the `build` > > directory's .m4 files and manually extract them (like I did for some > > of the shared ones previously). The ones with the highest versions > > will be the "minimum version required" to build geany-plugins (as a > > whole). > > Maybe building a script doing this would be a good idea. Having checked a couple of them I found it will be hard as they differ in way defining the dependencies... Cheers, Frank -- http://frank.uvena.de/en/ pgpgBdRN36CpM.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins Dependency Consolidation
On Sun, 05 Aug 2012 05:27:08 -0700 Matthew Brush wrote: > On 12-08-05 04:47 AM, Frank Lanitz wrote: > > On Sun, 5 Aug 2012 10:21:04 +1000 > > Lex Trotman wrote: > > > >> On 5 August 2012 03:40, Matthew Brush wrote: > >>> On 12-08-04 09:41 AM, Colomban Wendling wrote: > > [...] > > 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. > > >>> > >>> You got it mostly. I just mean some way for the build system to > >>> handle multiple plugins sharing same dependencies like having > >>> webkit.m4 that enables/disables multiple plugins if not found. So > >>> when you configure, it says something like this: > >>> > >>>checking for WebKit >= x.xx ... no > >>> Disabling plugins: WebHelper, Devhelp, Markdown > >> > >> I don't see this, the *plugin* should define what it needs, not > >> some arbitrary external build script. My (limited) understanding > >> of the plugin autofoo is that is how its done now by having local > >> build scripts in each plugin. > >> > > Yeah, and currently the plugins each check for the same shared > dependencies, but it doesn't show what they're checking for, it just > shows the plugin's name, like: > > checking for DEVHELP ... no > > What I'm asking about is to have a webkit.m4 (for example) or > something that the plugins which use that dependency can make use of > and so the check is only done once and if not found, it ouputs as I > said previously. Of course I don't know if it's realistic/feasible, > which is why I was asking. Sounds like a great idea. I support this wish. > >> If they require different versions that might mean you get > >> Webhelper and Devhelp but not Markdown, but your scheme won't > >> allow that. So if the Markdown dev added some new feature that > >> needed a higher version I can't build the other two unless I > >> upgrade my system :( > >> > > I mean they should require the same version, the same *lowest* > version they can work with (even if they need some minor changes to > make it possible). Should but not have to. I agree. > >> We should not be forcing the *highest* version needed by plugins. > > > > Not what I meant. But it's sort of what we do now if you consider > building geany-plugins as a whole. > > > I agree. But I also see the point of consolidation of dependencies. > > Its getting really complicated to say geany-plugins needs this > > dependencies, but I think its an issue we need to solve on social > > level, not trying to solve it with some hack. Is there any chance > > to get a complete list which plugins depend on which library out of > > autotools? > > > > What I was asking about wouldn't be a hack, it would just be to > change the plugins a bit so they depend on the same version of shared > libraries, and then to have Autotools do a check for the shared > dependency. Yes. It's mainly not a technical issue. Just some social issue where developers/maintainer have to talk to each other. > For a list of the dependencies, you can look through the `build` > directory's .m4 files and manually extract them (like I did for some > of the shared ones previously). The ones with the highest versions > will be the "minimum version required" to build geany-plugins (as a > whole). Maybe building a script doing this would be a good idea. Cheers, Frank -- http://frank.uvena.de/en/ pgpE6ivcX38J3.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins Dependency Consolidation
On Sun, 5 Aug 2012 22:24:12 +1000 Lex Trotman wrote: > On 5 August 2012 21:47, Frank Lanitz wrote: > > On Sun, 5 Aug 2012 10:21:04 +1000 > > Lex Trotman wrote: > > > >> On 5 August 2012 03:40, Matthew Brush wrote: > >> > On 12-08-04 09:41 AM, Colomban Wendling wrote: > >> >> > >> >> [...] > >> >> > >> >> 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. > >> >> > >> > > >> > You got it mostly. I just mean some way for the build system to > >> > handle multiple plugins sharing same dependencies like having > >> > webkit.m4 that enables/disables multiple plugins if not found. So > >> > when you configure, it says something like this: > >> > > >> > checking for WebKit >= x.xx ... no > >> > Disabling plugins: WebHelper, Devhelp, Markdown > >> > >> I don't see this, the *plugin* should define what it needs, not > >> some arbitrary external build script. My (limited) understanding > >> of the plugin autofoo is that is how its done now by having local > >> build scripts in each plugin. > >> > >> If they require different versions that might mean you get > >> Webhelper and Devhelp but not Markdown, but your scheme won't > >> allow that. So if the Markdown dev added some new feature that > >> needed a higher version I can't build the other two unless I > >> upgrade my system :( > >> > >> We should not be forcing the *highest* version needed by plugins. > > > > I agree. But I also see the point of consolidation of dependencies. > > Its getting really complicated to say geany-plugins needs this > > dependencies, > > Well, I am not sure that we should be saying "geany-plugins" has > dependencies anyway. IIUC, at least Debian packages each plugin > separately anyway. I can't speak for other distros but it makes sense > for users to be able to get just the plugins they want. > > Building the whole lot from source or git is fine, plugins that don't > have their needs met don't build, but do tell you about it. > > > but I think its an issue we need to solve on social level, not > > trying > > So I agree with Colomban, that there isn't anything to "solve", > different plugins have different dependencies, thats life. My goal is not to synchronize dependencies with a sword in my hand. I'm thinking about having a single point where the self-compiling use is able to check which version is needed for which plugin. So maybe an extension of Matthew's list inside a global INSTALL/README/whatever Cheers, Frank -- http://frank.uvena.de/en/ pgpoHC8kVoq1y.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins Dependency Consolidation
On 12-08-05 04:47 AM, Frank Lanitz wrote: On Sun, 5 Aug 2012 10:21:04 +1000 Lex Trotman wrote: On 5 August 2012 03:40, Matthew Brush wrote: On 12-08-04 09:41 AM, Colomban Wendling wrote: [...] 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. You got it mostly. I just mean some way for the build system to handle multiple plugins sharing same dependencies like having webkit.m4 that enables/disables multiple plugins if not found. So when you configure, it says something like this: checking for WebKit >= x.xx ... no Disabling plugins: WebHelper, Devhelp, Markdown I don't see this, the *plugin* should define what it needs, not some arbitrary external build script. My (limited) understanding of the plugin autofoo is that is how its done now by having local build scripts in each plugin. Yeah, and currently the plugins each check for the same shared dependencies, but it doesn't show what they're checking for, it just shows the plugin's name, like: checking for DEVHELP ... no What I'm asking about is to have a webkit.m4 (for example) or something that the plugins which use that dependency can make use of and so the check is only done once and if not found, it ouputs as I said previously. Of course I don't know if it's realistic/feasible, which is why I was asking. If they require different versions that might mean you get Webhelper and Devhelp but not Markdown, but your scheme won't allow that. So if the Markdown dev added some new feature that needed a higher version I can't build the other two unless I upgrade my system :( I mean they should require the same version, the same *lowest* version they can work with (even if they need some minor changes to make it possible). We should not be forcing the *highest* version needed by plugins. Not what I meant. But it's sort of what we do now if you consider building geany-plugins as a whole. I agree. But I also see the point of consolidation of dependencies. Its getting really complicated to say geany-plugins needs this dependencies, but I think its an issue we need to solve on social level, not trying to solve it with some hack. Is there any chance to get a complete list which plugins depend on which library out of autotools? What I was asking about wouldn't be a hack, it would just be to change the plugins a bit so they depend on the same version of shared libraries, and then to have Autotools do a check for the shared dependency. For a list of the dependencies, you can look through the `build` directory's .m4 files and manually extract them (like I did for some of the shared ones previously). The ones with the highest versions will be the "minimum version required" to build geany-plugins (as a whole). Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins Dependency Consolidation
On 5 August 2012 21:47, Frank Lanitz wrote: > On Sun, 5 Aug 2012 10:21:04 +1000 > Lex Trotman wrote: > >> On 5 August 2012 03:40, Matthew Brush wrote: >> > On 12-08-04 09:41 AM, Colomban Wendling wrote: >> >> >> >> [...] >> >> >> >> 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. >> >> >> > >> > You got it mostly. I just mean some way for the build system to >> > handle multiple plugins sharing same dependencies like having >> > webkit.m4 that enables/disables multiple plugins if not found. So >> > when you configure, it says something like this: >> > >> > checking for WebKit >= x.xx ... no >> > Disabling plugins: WebHelper, Devhelp, Markdown >> >> I don't see this, the *plugin* should define what it needs, not some >> arbitrary external build script. My (limited) understanding of the >> plugin autofoo is that is how its done now by having local build >> scripts in each plugin. >> >> If they require different versions that might mean you get Webhelper >> and Devhelp but not Markdown, but your scheme won't allow that. So if >> the Markdown dev added some new feature that needed a higher version I >> can't build the other two unless I upgrade my system :( >> >> We should not be forcing the *highest* version needed by plugins. > > I agree. But I also see the point of consolidation of dependencies. Its > getting really complicated to say geany-plugins needs this dependencies, Well, I am not sure that we should be saying "geany-plugins" has dependencies anyway. IIUC, at least Debian packages each plugin separately anyway. I can't speak for other distros but it makes sense for users to be able to get just the plugins they want. Building the whole lot from source or git is fine, plugins that don't have their needs met don't build, but do tell you about it. > but I think its an issue we need to solve on social level, not trying So I agree with Colomban, that there isn't anything to "solve", different plugins have different dependencies, thats life. However I agree that checking what dependencies are specified is worthwhile from time to time, to make sure that the list is right in Autofoo and the documentation. Cheers Lex > to solve it with some hack. Is there any chance to get a complete list > which plugins depend on which library out of autotools? > > Cheers, > Frank > -- > http://frank.uvena.de/en/ > > ___ > Geany-devel mailing list > Geany-devel@uvena.de > https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel > ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins Dependency Consolidation
On Sun, 5 Aug 2012 10:21:04 +1000 Lex Trotman wrote: > On 5 August 2012 03:40, Matthew Brush wrote: > > On 12-08-04 09:41 AM, Colomban Wendling wrote: > >> > >> [...] > >> > >> 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. > >> > > > > You got it mostly. I just mean some way for the build system to > > handle multiple plugins sharing same dependencies like having > > webkit.m4 that enables/disables multiple plugins if not found. So > > when you configure, it says something like this: > > > > checking for WebKit >= x.xx ... no > > Disabling plugins: WebHelper, Devhelp, Markdown > > I don't see this, the *plugin* should define what it needs, not some > arbitrary external build script. My (limited) understanding of the > plugin autofoo is that is how its done now by having local build > scripts in each plugin. > > If they require different versions that might mean you get Webhelper > and Devhelp but not Markdown, but your scheme won't allow that. So if > the Markdown dev added some new feature that needed a higher version I > can't build the other two unless I upgrade my system :( > > We should not be forcing the *highest* version needed by plugins. I agree. But I also see the point of consolidation of dependencies. Its getting really complicated to say geany-plugins needs this dependencies, but I think its an issue we need to solve on social level, not trying to solve it with some hack. Is there any chance to get a complete list which plugins depend on which library out of autotools? Cheers, Frank -- http://frank.uvena.de/en/ pgpl6kSkojQ91.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins Dependency Consolidation
On 5 August 2012 03:40, Matthew Brush wrote: > On 12-08-04 09:41 AM, Colomban Wendling wrote: >> >> [...] >> >> 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. >> > > You got it mostly. I just mean some way for the build system to handle > multiple plugins sharing same dependencies like having webkit.m4 that > enables/disables multiple plugins if not found. So when you configure, it > says something like this: > > checking for WebKit >= x.xx ... no > Disabling plugins: WebHelper, Devhelp, Markdown I don't see this, the *plugin* should define what it needs, not some arbitrary external build script. My (limited) understanding of the plugin autofoo is that is how its done now by having local build scripts in each plugin. If they require different versions that might mean you get Webhelper and Devhelp but not Markdown, but your scheme won't allow that. So if the Markdown dev added some new feature that needed a higher version I can't build the other two unless I upgrade my system :( We should not be forcing the *highest* version needed by plugins. Cheers Lex > checking for LibVTE >= x.xx ... no > Disabling plugins: Debugger, MultiTerm > > Instead of: > > checking for WEBHELPER ... no > checking for DEVHELP ... yes > checking for MARKDOWN ... no > checking for DEBUGGER ... no > checking for MULTITERM ... yes > > Plugins: > WebHelper no > Devhelp yes > Markdownno > Debuggerno > MultiTerm yes > > Cheers, > Matthew Brush > > > ___ > Geany-devel mailing list > Geany-devel@uvena.de > https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins Dependency Consolidation
On 12-08-04 09:41 AM, Colomban Wendling wrote: [...] 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. You got it mostly. I just mean some way for the build system to handle multiple plugins sharing same dependencies like having webkit.m4 that enables/disables multiple plugins if not found. So when you configure, it says something like this: checking for WebKit >= x.xx ... no Disabling plugins: WebHelper, Devhelp, Markdown checking for LibVTE >= x.xx ... no Disabling plugins: Debugger, MultiTerm Instead of: checking for WEBHELPER ... no checking for DEVHELP ... yes checking for MARKDOWN ... no checking for DEBUGGER ... no checking for MULTITERM ... yes Plugins: WebHelper no Devhelp yes Markdownno Debuggerno MultiTerm yes Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins Dependency Consolidation
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
[Geany-devel] Geany-Plugins Dependency Consolidation
Hi, 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: * GdkPixbuf - WebHelper - v2.0 * GTK+ - Devhelp - v2.16 - GenDoc - v2.12 - MultiTerm - version unspecified - WebHelper - v2.16 * GLIB - GenDoc - v2.14 - WebHelper - v2.16 * GIO - GenDoc - v2.18 - TreeBrowser - version unspecified - WebHelper - v2.18 * GModule - GeanyLua - version unspecified * GThread - WebHelper - version unspecified * LibSoup - GeniusPaste - v2.4 - UpdateChecker - v2.4 * LibVTE - Debugger - v0.24 - MultiTerm - version unspecified * LibXML - PrettyPrinter - v2.6.27 - XMLSnippets - either doesn't use or not specified * WebKitGTK+ - Devhelp - 1.1.13 - WebHelper - v1.1.18 - Markdown (Future Plugin) - version unspecified 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. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
