On Jan 10, 2008 2:29 PM, Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 9 Jan 2008 17:13:21 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
If the Lua plugin was distributed with Geany, Lua can be an optional dependency - probably we could disable building of geanylua if there were no lua headers found when running ./configure. Distros could then package geany-lua-plugin as a separate package. Anyway, I'm not sure if everyone wants to do this, maybe not ;-)
I'd be fine with that. Especially the idea of only enabling to build/install it when Lua headers are found is great.
It's up to Jeff now ;-).
Sounds good to me!
A few minor issues come to mind:
* The code is formatted a bit differently than the Geany "standard". I am mostly accustomed to using a two-space indent and although I used tabs for the geanylua code, my tab width is set at two, so the code looks pretty bad if you look at with tabwidth=4.
* There are a few other differences in our coding styles. For me, if something is NULL then it's false, so you won't find a lot of "if (something != NULL)" in my code it's just "if (something)". I also tend to use *lots* of parenthesis instead of depending on operator precedence. (I guess you could call me "algebraically challenged" :-)
* The documentation is hand edited HTML, I tried to make it look similar to the Lua docs, I'm not sure how well it would "fit" with the Geany docs.
So if you are asking me to maintain the geanylua code from inside the Geany codebase, I would like to preserve these little formatting idiosyncrasies. Of course, the code is GPL, so if you'd rather just maintain it yourself you are certainly free to change it any way you please. ;-)
Also, there is no Win32 makefile for geanylua. The windows build uses autotools just like the rest. I know there are good and bad points to both approaches, but IMO the main purpose of autotools is to provide cross platform support.
I guess either approach will work, but I imagine that using both methods within the same source tree might cause some problems.
Having said all that, I think there are also some big advantages to having the two projects more closely integrated. There is a horrible kludge in my configure.in file that tries to guess the Geany version and installation directories using --version and --print-prefix. I would really love to able to rip that crap out completely and just let Geany decide where to install the plugin. I am also having a terrible time trying to load third-party modules into Lua, and I think *possibly* there might be a way to solve the problem by passing some extra flags to the linker when Geany is built to support Lua.
I'm sure there will still be some other points to work out, but nothing we can't handle...
- Jeff