[Geany-devel] build plugin - Re: Build system branch 2.0

[Nick Treleaven]

On Thu, 25 Feb 2010 09:43:33 +1100
Lex Trotman <elextr at gmail.com> wrote:

> On 25 February 2010 00:17, Nick Treleaven <nick.treleaven at btinternet.com>wrote:
> 
> > 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