Hi all,
I've just uploaded the geany-plugins-0.17 gz and bz2 tarballs to http://plugins.geany.org, and updated the web pages accordingly. This marks our first combined release of the Geany plugins. Have fun with it =)
On Fri, 10 Jul 2009 06:07:13 +0800 Chow Loong Jin hyperair@gmail.com wrote:
Hi all,
I've just uploaded the geany-plugins-0.17 gz and bz2 tarballs to http://plugins.geany.org, and updated the web pages accordingly. This marks our first combined release of the Geany plugins. Have fun with it
Great work :)
I've updated http://www.geany.org/Support/Plugins.
We'll need to make a news announcement on the site also.
Regards, Nick
Hi Chow,
I have reported this previously (see [geany-plugins-Bugs-2783412]) when Enrico and I decided that we didn't know enough autotools to fix it quickly, but now that your expertise is available maybe you can fix it.
Basically the plugins cannot be used with a version of geany that is installed in any directory other than the standard, if there is also a version installed in the standard location. ie geany configured with --prefix=somewhere is fine but geany-plugins configured with --prefix=somewhere still goes to /usr/lib and /usr/include instead of somewhere/lib & somewhere/include.
This means that new versions can't be tested while there is still a system installed version.
Essentially the plugins builder should respect --prefix if present otherwise use pkg-config to find the installed version.
Cheers Lex
2009/7/10 Chow Loong Jin hyperair@gmail.com
Hi all,
I've just uploaded the geany-plugins-0.17 gz and bz2 tarballs to http://plugins.geany.org, and updated the web pages accordingly. This marks our first combined release of the Geany plugins. Have fun with it =)
-- Kind regards, Chow Loong Jin
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Friday 17,July,2009 09:06 AM, Lex Trotman wrote:
Hi Chow,
I have reported this previously (see [geany-plugins-Bugs-2783412]) when Enrico and I decided that we didn't know enough autotools to fix it quickly, but now that your expertise is available maybe you can fix it.
Basically the plugins cannot be used with a version of geany that is installed in any directory other than the standard, if there is also a version installed in the standard location. ie geany configured with --prefix=somewhere is fine but geany-plugins configured with --prefix=somewhere still goes to /usr/lib and /usr/include instead of somewhere/lib & somewhere/include.
I don't think geany-plugins has any include files does it? Or are you talking about geany? Either way, geany-plugins installs its own files into the prefix given by --prefix, but installs the actual plugins into the Geany plugins directory (Geany's prefix/lib) given by pkg-config. The reason this is done is because Geany wouldn't be able to find the plugin to load otherwise.
This means that new versions can't be tested while there is still a system installed version.
Essentially the plugins builder should respect --prefix if present otherwise use pkg-config to find the installed version.
How about a --with-geany-pluginsdir=PATH argument instead? I think --prefix serves a rather different purpose.
Hi,
2009/7/17 Chow Loong Jin hyperair@gmail.com:
On Friday 17,July,2009 09:06 AM, Lex Trotman wrote:
Hi Chow,
I have reported this previously (see [geany-plugins-Bugs-2783412]) when Enrico and I decided that we didn't know enough autotools to fix it quickly, but now that your expertise is available maybe you can fix it.
Basically the plugins cannot be used with a version of geany that is installed in any directory other than the standard, if there is also a version installed in the standard location. ie geany configured with --prefix=somewhere is fine but geany-plugins configured with --prefix=somewhere still goes to /usr/lib and /usr/include instead of somewhere/lib & somewhere/include.
I don't think geany-plugins has any include files does it?
I mean the geany .h files that define the plugin interface and which geany plugins includes when it builds. They are in ${prefix}/include/geany Also needs to link with libraries in ${prefix}/lib/geany
Or are you
talking about geany? Either way, geany-plugins installs its own files into the prefix given by --prefix, but installs the actual plugins into the Geany plugins directory (Geany's prefix/lib) given by pkg-config. The reason this is done is because Geany wouldn't be able to find the plugin to load otherwise.
Sure but a Geany built by configure --prefix xxx; make install will not leave a pkg-config trail AFAIK, and if it did it would then hide the system installed version.
Update to this, it leaves it in ${prefix}/lib/pkgconfig so maybe what needs to be done is to point pkg-config at that somehow. Example attached which shows the right symbol values from the Geany make. The plugins just need to use the same.
This means that new versions can't be tested while there is still a system installed version.
Essentially the plugins builder should respect --prefix if present otherwise use pkg-config to find the installed version.
How about a --with-geany-pluginsdir=PATH argument instead? I think --prefix serves a rather different purpose.
Maybe an option needs to point at the pkg-config & then all the symbols can come from there.
Cheers Lex
-- Kind regards, Chow Loong Jin
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Friday 17,July,2009 01:11 PM, Lex Trotman wrote:
Hi,
I don't think geany-plugins has any include files does it?
I mean the geany .h files that define the plugin interface and which geany plugins includes when it builds. They are in ${prefix}/include/geany Also needs to link with libraries in ${prefix}/lib/geany
AFAIK, ${prefix}/lib/geany contains only plugins, and they should not be used for linking.
Or are you
talking about geany? Either way, geany-plugins installs its own files into the prefix given by --prefix, but installs the actual plugins into the Geany plugins directory (Geany's prefix/lib) given by pkg-config. The reason this is done is because Geany wouldn't be able to find the plugin to load otherwise.
Sure but a Geany built by configure --prefix xxx; make install will not leave a pkg-config trail AFAIK, and if it did it would then hide the system installed version.
Update to this, it leaves it in ${prefix}/lib/pkgconfig so maybe what needs to be done is to point pkg-config at that somehow. Example attached which shows the right symbol values from the Geany make. The plugins just need to use the same.
This means that new versions can't be tested while there is still a system installed version.
Essentially the plugins builder should respect --prefix if present otherwise use pkg-config to find the installed version.
How about a --with-geany-pluginsdir=PATH argument instead? I think --prefix serves a rather different purpose.
Maybe an option needs to point at the pkg-config & then all the symbols can come from there.
Alright, so the current structure is something like this: ${DESTDIR} |-- ${geany_plugins_prefix} | |-- lib | | `-- geany-plugins | | `-- ${plugin} | | `-- files | `-- share | |-- doc | | `-- geany-plugins | | `-- ${plugin} | | `-- files | `-- geany-plugins | `-- ${plugin} | `-- files `-- ${geany_prefix} `-- lib `-- geany |-- ${plugin}.la `-- ${plugin}.so
Currently, ${geany_prefix} is grabbed from geany.pc using pkg-config, not customizable, and ${geany_plugins_prefix} defaults to /usr/local, customizable via --prefix=PATH. Incidentally, ${geany_prefix} also contains Geany's include files.
From what I understand, what we want here is the ability to customize ${geany_prefix}. The way I see it, we have two options of implementing this functionality. The first is to keep ${geany_plugins_prefix} separate from ${geany_prefix}, or to force them to be the same.
In the first case, we would have ${geany_plugins_prefix} set by --prefix=PATH, and ${geany_prefix} set by --with-geany-prefix=PATH.
In the second case, we force ${geany_plugins_prefix} to be = ${geany_prefix}, so we default ${geany_plugins_prefix} and ${geany_prefix} to the prefix grabbed from geany.pc, and then let both paths to be customized using --prefix=PATH.
In both cases, PKG_CONFIG_PATH will be set to ${geany_prefix}/lib/pkgconfig in order to make sure the correct include files are used when using pkg-config --cflags.
I'd like to hear opinions from the plugin developers as to which is more favourable before making any changes.
2009/7/17 Chow Loong Jin hyperair@gmail.com:
On Friday 17,July,2009 01:11 PM, Lex Trotman wrote:
Hi,
I don't think geany-plugins has any include files does it?
I mean the geany .h files that define the plugin interface and which geany plugins includes when it builds. They are in ${prefix}/include/geany Also needs to link with libraries in ${prefix}/lib/geany
AFAIK, ${prefix}/lib/geany contains only plugins, and they should not be used for linking.
You're right, they are created not linked by plugins
Or are you
talking about geany? Either way, geany-plugins installs its own files into the prefix given by --prefix, but installs the actual plugins into the Geany plugins directory (Geany's prefix/lib) given by pkg-config. The reason this is done is because Geany wouldn't be able to find the plugin to load otherwise.
Sure but a Geany built by configure --prefix xxx; make install will not leave a pkg-config trail AFAIK, and if it did it would then hide the system installed version.
Update to this, it leaves it in ${prefix}/lib/pkgconfig so maybe what needs to be done is to point pkg-config at that somehow. Example attached which shows the right symbol values from the Geany make. The plugins just need to use the same.
This means that new versions can't be tested while there is still a system installed version.
Essentially the plugins builder should respect --prefix if present otherwise use pkg-config to find the installed version.
How about a --with-geany-pluginsdir=PATH argument instead? I think --prefix serves a rather different purpose.
Maybe an option needs to point at the pkg-config & then all the symbols can come from there.
Alright, so the current structure is something like this: ${DESTDIR} |-- ${geany_plugins_prefix} | |-- lib | | `-- geany-plugins | | `-- ${plugin} | | `-- files | `-- share | |-- doc | | `-- geany-plugins | | `-- ${plugin} | | `-- files | `-- geany-plugins | `-- ${plugin} | `-- files `-- ${geany_prefix} `-- lib `-- geany |-- ${plugin}.la `-- ${plugin}.so
Currently, ${geany_prefix} is grabbed from geany.pc using pkg-config, not customizable, and ${geany_plugins_prefix} defaults to /usr/local, customizable via --prefix=PATH. Incidentally, ${geany_prefix} also contains Geany's include files.
From what I understand, what we want here is the ability to customize ${geany_prefix}. The way I see it, we have two options of implementing this functionality. The first is to keep ${geany_plugins_prefix} separate from ${geany_prefix}, or to force them to be the same.
Happy either way, so long as its documented, plugins creators should choose.
Cheers Lex
In the first case, we would have ${geany_plugins_prefix} set by --prefix=PATH, and ${geany_prefix} set by --with-geany-prefix=PATH.
In the second case, we force ${geany_plugins_prefix} to be = ${geany_prefix}, so we default ${geany_plugins_prefix} and ${geany_prefix} to the prefix grabbed from geany.pc, and then let both paths to be customized using --prefix=PATH.
In both cases, PKG_CONFIG_PATH will be set to ${geany_prefix}/lib/pkgconfig in order to make sure the correct include files are used when using pkg-config --cflags.
I'd like to hear opinions from the plugin developers as to which is more favourable before making any changes.
-- Kind regards, Chow Loong Jin
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi Chow,
I had the following problem making the combined plugins on an older machine,
aclocal: unrecognized option -- `--install'
This was aclocal version 1.9.6 on Zen 4.2 (18 months old)
Fixed with upgrade to aclocal 1.10.1
Given that Geany still supports GTK 2.8 which is twice as old, the plugins may encounter even older tools.
So the requirement for aclocal >?? needs to be documented somewhere or required somehow.
Cheers Lex
On Tuesday 21,July,2009 11:03 AM, Lex Trotman wrote:
Hi Chow,
I had the following problem making the combined plugins on an older machine,
aclocal: unrecognized option -- `--install'
This was aclocal version 1.9.6 on Zen 4.2 (18 months old)
Fixed with upgrade to aclocal 1.10.1
Given that Geany still supports GTK 2.8 which is twice as old, the plugins may encounter even older tools.
So the requirement for aclocal >?? needs to be documented somewhere or required somehow.
Hmm perhaps the autogen.sh script could be rewritten or taken from elsewhere. Could you test if using Geany's autogen.sh script in the geany-plugins directory works? Just copy it over and run ./autogen.sh. You probably have to create a build/cache directory first beforehand.
2009/7/21 Chow Loong Jin hyperair@gmail.com:
On Tuesday 21,July,2009 11:03 AM, Lex Trotman wrote:
Hi Chow,
I had the following problem making the combined plugins on an older machine,
aclocal: unrecognized option -- `--install'
This was aclocal version 1.9.6 on Zen 4.2 (18 months old)
Fixed with upgrade to aclocal 1.10.1
Given that Geany still supports GTK 2.8 which is twice as old, the plugins may encounter even older tools.
So the requirement for aclocal >?? needs to be documented somewhere or required somehow.
Hmm perhaps the autogen.sh script could be rewritten or taken from elsewhere. Could you test if using Geany's autogen.sh script in the geany-plugins directory works? Just copy it over and run ./autogen.sh. You probably have to create a build/cache directory first beforehand.
error: '.' does not look like the top-level package directory
And even if it worked I'm not sure if it would have been a valid test as aclocal has been upgraded.
Cheers Lex
-- Kind regards, Chow Loong Jin
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 17 Jul 2009 14:06:23 +0800 Chow Loong Jin hyperair@gmail.com wrote:
Alright, so the current structure is something like this: ${DESTDIR} |-- ${geany_plugins_prefix} | |-- lib | | `-- geany-plugins | | `-- ${plugin} | | `-- files | `-- share | |-- doc | | `-- geany-plugins | | `-- ${plugin} | | `-- files | `-- geany-plugins | `-- ${plugin} | `-- files `-- ${geany_prefix} `-- lib `-- geany |-- ${plugin}.la `-- ${plugin}.so
Currently, ${geany_prefix} is grabbed from geany.pc using pkg-config, not customizable,
Maybe Lex can just use: PKG_CONFIG_PATH=${geany_prefix}/lib/pkgconfig ./configure
to use a Geany installed elsewhere.
But to use the normal Geany with the new 'Extra plugin path' pref I suppose geany-plugins would need to support setting a custom plugin .so path. This might make more sense than allowing a custom ${geany_prefix}, because that can (probably) be done with the PKG_CONFIG_PATH method above.
So if this is correct, I think maybe just add the --with-geany-plugins-dir=PATH as you suggested earlier, although using pkg-config might be enough.
Regards, Nick
On Fri, 17 Jul 2009 14:05:58 +0100, Nick wrote:
But to use the normal Geany with the new 'Extra plugin path' pref I suppose geany-plugins would need to support setting a custom plugin .so path. This might make more sense than allowing a custom ${geany_prefix}, because that can (probably) be done with the PKG_CONFIG_PATH method above.
So if this is correct, I think maybe just add the --with-geany-plugins-dir=PATH as you suggested earlier, although using pkg-config might be enough.
I agree with Nick. Change as few as possible to the current way it's done. I think the stuff is good enough for most use cases and Lex' problem with a different ${geany_prefix} should be solved by using a proper PKG_CONFIG_PATH value and the 'Extra plugin path' preference.
Regards, Enrico