[PATCH] Build configuration hints

[Nicolai Hähnle]

Am Samstag 16 Februar 2008 22:45:24 schrieb Andreas Pakulat:
> As for notification of empty buildsets: I'm going to simply disable the
> actions (and have proper tooltips) when the buildset is empty. I'm not
> sure yet, but maybe this will also move into a submenu called "Buildset"
> or some such.

Okay. Maybe the '+' button in the Project Manager view should also be disabled 
when the tree view has no selection?

> And about notifying of failed builds:  Two problems
> - the building shouldn't break on the first item that is not buildable,
>   items might belong to different independant projects so building
>   should only skip items that depend on a non-buildable item. Thats
>   something on my todo list.

Maybe I should explain my line of thought that lead to the patch.

First of all, just calling IBuildReport::configure before the build won't work 
in the situation that I wanted to address, where the build directory etc. 
isn't set up. Ideally, the Configure Project dialog would be shown in this 
case, but I didn't figure out how to access that. Maybe I should look into 
that.

Now, guiding the user to the Configure Project dialog is very useful, but it 
messes with modality in a way that could be confusing. (Consider that a new 
user can spend significant time trying to understand that dialog, and by the 
time they're done with it, they might not even want to go ahead with the 
build.) Therefore, I thought it would be best to just return to a completely 
neutral state (i.e. no further builds) after the dialog interruption.

Another side note is that the entire new code path is not triggered by 
classical build failures like compiler/linker errors, but only by 
misconfigurations of the build system.

To summarize:
1) I did think about the problem of building several, unrelated items.
2) I came to the conclusion that interrupting the build in the case of a 
significant build system misconfiguration is preferable. (Note the 
distinction between misconfiguration and compiler error.)
3) If you come to a different conclusion, that's obviously fine, too.

> - the message box should be implemented in the individual build plugins
>   as they may have more specific information about why the building
>   failed.

Sounds good.

cu,
Nicolai