Re: Build configuration hints

On 16.02.08 18:00:38, Nicolai Hähnle wrote:
> #2: Add tooltips to the buildset '+' and '-' buttons in
the Project Manager 
> view.

I just applied and comitted that one. Thanks.

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.

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.

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

Cc'ing kdevelop-devel as most devs don't read this list
(unfortunately),
please CC to the kdevelop user list when replying so Nicolai
can follow
the discussion.

Andreas

-- 
Never reveal your best argument.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Saturday 16 February 2008 22:45:24 Andreas Pakulat
wrote:

> 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.

In most cases that I can think of, breaking after the first
built item would 
be better.(example: build kdelibs, then kdevplatform, then
kdevelop). So 
maybe there should be a very simple way of configuring that
on the fly.

greetings, David

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

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

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel