On Sun, 05 Aug 2012 05:27:08 -0700 Matthew Brush <mbr...@codebrainz.ca> wrote:
> On 12-08-05 04:47 AM, Frank Lanitz wrote: > > On Sun, 5 Aug 2012 10:21:04 +1000 > > Lex Trotman <ele...@gmail.com> wrote: > > > >> On 5 August 2012 03:40, Matthew Brush <mbr...@codebrainz.ca> 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
