On Thu, 25 Feb 2010 09:43:33 +1100 Lex Trotman elextr@gmail.com wrote:
On 25 February 2010 00:17, Nick Treleaven nick.treleaven@btinternet.comwrote:
Personally I'm not sure that tying the two implementations together is a good idea. I haven't really studied Lex's build.c implementation but I don't want to have to expose all of it to the plugin API. This will straightjacket any changes we want to make on the core build system.
Totally agree, thats why I am proposing to change it so that only the configuration interface be exposed (see attached proposed interface).
This interface is narrow, typesafe, and expandable but exposes little of the internal workings because the BuildOperation type is opaque. It is also ABI safe if extra fields and functions are added and still ABI safe if enums are extended and API safe if no functions/enums are removed.
Yes, but exposing an interface puts controls on what our build code must do. It's hard to define interfaces well with foresight. It adds a significant maintenance burden.
Anyway, if you and Enrico want to do this I suppose it's OK, but obviously if we need to change the core we will try to maintain the API but we may need to break it from time to time.
This API also makes it possible for other plugins to manipulate settings such as Franks proposed plugin that sets build commands based on contents of latex files.
OK.
One option would be for a plugin to completely replace the build system by hiding the build menu and overriding the build keybindings.
This would make loading/storing settings messy, the filetypes, project and preferences load/store interface needs to be available to the plugin. And what happens if the plugin isn't loaded when the filetypes etc are loaded? When the plugin is loaded how does it get to re-load these settings? Or does the plugin have to have another set of settings files mirroring the filetype projects and preferences files? And structures mirroring the GeanyFiletype, GeanyProject etc structures or do those structures have fields for a plugin that may not be loaded?
As independent as possible, so all settings in a separate config file. Remember you want settings that we don't need for the core.
Makes the plugin much bigger and also requires more of the build
Makes the core smaller ;-)
functionality to be exposed unless everything is re-implemented in the plugin in which case maintenance is a nightmare to keep them in line. For example the build_command, build_run _cmd, build_replace_placeholder functions.
Why keep them in line?
Anyway you might be right that it's less work for you if we share the build.c functionality. I'm not really convinced that it's necessary to have 'delta' level control on each command - I think it would be best to improve the core to allow advanced users to do anything they want but in a structured way that doesn't confuse basic users.
But don't let me stop you, just wanted to air my thoughts ;-)
Regards, Nick