Re: [Geany-devel] Geany-Plugins Dependency Consolidation

2012-08-04 Thread Colomban Wendling
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


Re: [Geany-devel] Geany-Plugins Dependency Consolidation

2012-08-04 Thread Matthew Brush

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

2012-08-04 Thread Lex Trotman
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.

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