Review Request: BuilderJob: (eye-candy) flatten composite job hierarchies and generate a meaningful job name

[Ivan Shapovalov]

> On Sept. 17, 2012, 11:53 a.m., Aleix Pol Gonzalez wrote:
> > project/builderjob.h, line 105
> > <http://git.reviewboard.kde.org/r/106461/diff/1/?file=85691#file85691line105>
> >
> >     Doesn't look like it should be public...
> >     
> >     protected, maybe?

I think so: let the creator call updateJobName() when it finishes adding jobs - just before it passes the job to the run controller.
Reason: regenerating the job name on each BuilderJob::addSomething() is costly, and the run controller queries the job's name right after it receives it.

We also may modify run controller itself so it will dynamic_cast and call updateJobName() when it needs to, but I'm not sure whether dynamic_casting is "good style".


> On Sept. 17, 2012, 11:53 a.m., Aleix Pol Gonzalez wrote:
> > project/builderjob.h, line 97
> > <http://git.reviewboard.kde.org/r/106461/diff/1/?file=85691#file85691line97>
> >
> >     Isn't it bit odd to have different jobs that will be run against different items?

Isn't. The whole "build set" (multiple targets/projects) is going to end up in a single job.
// Anticipating your question about "why is it going to end up in a single job": it was so before, but there was a hierarchy of composite jobs. Now it will be just one composite job.


- Ivan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106461/#review19060
-----------------------------------------------------------


On Sept. 17, 2012, 7:51 a.m., Ivan Shapovalov wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106461/
> -----------------------------------------------------------
> 
> (Updated Sept. 17, 2012, 7:51 a.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Description
> -------
> 
> 1. If a BuilderJob is added into another BuilderJob, the latter's subjobs are inserted into the former rather than having two nested composite jobs.
> 2. A BuilderJob has its name generated from its contents (this is real eye-candy).
> 
> 
> Diffs
> -----
> 
>   plugins/execute/executeplugin.cpp 817c082 
>   plugins/projectmanagerview/projectmanagerviewplugin.cpp 968376d 
>   project/builderjob.h 297f187 
>   project/builderjob.cpp 44519d3 
> 
> Diff: http://git.reviewboard.kde.org/r/106461/diff/
> 
> 
> Testing
> -------
> 
> Existing unit-tests, various hand-testing.
> 
> 
> Thanks,
> 
> Ivan Shapovalov
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120917/255937bd/attachment.html>