[PATCH] Build configuration hints
nhaehnle at gmail.com
Sun Feb 17 00:13:54 UTC 2008
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
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.
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
More information about the KDevelop