share code between makebuilder and external scripts

[Andreas Pakulat]

On 22.09.10 04:08:59, Milian Wolff wrote:
> On Wednesday 22 September 2010 00:25:02 Aleix Pol wrote:
> > On Tue, Sep 21, 2010 at 11:03 PM, Milian Wolff <mail at milianw.de> wrote:
> > > Hey guys,
> > > 
> > > I need your feedback on this. Apparently some people are using my
> > > external scripts plugin to run some magic build scripts, like e.g.:
> > > 
> > > https://bugs.kde.org/show_bug.cgi?id=251983
> > > 
> > > This is great since that was definitely one of the reasons I wrote that
> > > plugin.
> > > Anyways, people are not yet satisfied and want (rightly so!) the features
> > > we
> > > give them for plain make build jobs, esp. the highlighting of
> > > errors/warnings
> > > and the ability to jump to those positions inside the code.
> > > 
> > > I want to give that to the users of custom buildsystems as well,
> > > currently I'd
> > > imagine a checkbox in the configuration of an external script, which you
> > > can
> > > tick to enable this "error detection".
> > > 
> > > What I want to prevent is duplicated code. The code for MakeJobs works
> > > fine it
> > > seems, so I'd be interested in reusing that. The real question is: how,
> > > without making it a API mess that cannot stay BC.
> > > 
> > > Right now I think the best way would be to put the code in
> > > MakeOutputModel::addLines , that decides whether a line has an error or
> > > action, into a library so one could reuse it. But I'm not sure whether
> > > returning a FilteredItem from this function is fine, considering BC. I
> > > could
> > > make it a proper class with dptr if it's preferred, or is using that
> > > struct there OK?
> > > 
> > > Furthermore I'd need MakeOutputDelegate and quite some code currently
> > > found in
> > > MakeOutputModel, like activate, next/prevHighlightIndex, urlForFile...
> > > 
> > > So should I maybe export the whole MakeOuputModel and rebase my own model
> > > on
> > > that somehow? I.e. put MakeOutputModel into kdevplatform/outputview?
> > > 
> > > Too many maybes, whats and unsures for me. Please give me some help :)
> > 
> > Maybe it would be easier to add support for custom targets? I think that
> > our makebuilder should support all kinds of interaction a developer might
> > need against make. No?
> > 
> > If you used the MakeOutputModel, how would you let the user tell if he's
> > using make command or not? isn't that workaround-ish?
> 
> As I said, a simply checkbox "output should be filtered for make messages" or 
> similar. Imo external scripts should have such a feature.
> 
> Or we add yet another way to build scripts by defining arbitrary shell commands 
> and add them as targets. I.e. a context menu entry on folders (not targets) 
> "New Target" or similar.
> 
> One could do that, and the idea is indeed nice. What do the others think?

I didn't add this yet (also because of the code-sharing problem), but
reading all that sounds like those people may want to have a look at the
custom buildsystem plugin. 

And for the output-filtering, we could extend the outputview api to
allow for output filtering via plugins with a filter-interface. Then the
make/gcc stuff could be moved into a plugin and implement that
filter-interface and whoever wants the filtering can then specify that
this filter should be used for the output. Not yet sure how to do the
'specify that this filter should be used' part, but I'd avoid using the
pluginname. Maybe it could even be a combobox in the output view
toolbar, so the user can select the filter he wants to apply.

Andreas

-- 
A few hours grace before the madness begins again.