Oops, forgot the CC
----- Forwarded message from Andreas Pakulat <apaku gmx.de> -----
Envelope-to: andreaslocalhost
Delivery-date: Sun, 17 Feb 2008 09:14:37 +0100
X-Flags: 0000
X-Authenticated: #15861332
From: Andreas Pakulat <apakugmx.de>
To: kdevelopbarney.cs.uni-potsdam.de
Subject: Re: [PATCH] Build configuration hints
Mail-Followup-To: kdevelopbarney.cs.uni-potsdam.de
X-BeenThere: kdevelopbarney.cs.uni-potsdam.de
X-Mailman-Version: 2.1.6
Reply-To: kdevelopkdevelop.org
List-Id: KDevelop's users list
<kdevelop.barney.cs.uni-potsdam.de>
List-Unsubscribe: <https://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop>,
<mailto:kdevelop-requestbarney.cs.uni-potsdam.de?subject=unsubscribe>
List-Archive: <https://barney.cs.uni-potsdam.de/mailman/private/kd
evelop>
List-Post: <mailto:kdevelopbarney.cs.uni-potsdam.de>
List-Help: <mailto:kdevelop-requestbarney.cs.uni-potsdam.de?subject=help>
List-Subscribe: <https://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop>,
<mailto:kdevelop-requestbarney.cs.uni-potsdam.de?subject=subscribe>
X-GMX-Antivirus: -1 (not scanned, may not use virus
scanner)
X-GMX-Antispam: -2 (not scanned, spam filter disabled)
X-GMX-UID: 94DcLzpSTlIvKTxjhWhrJztGU2poZRnh
X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000,
version=1.1.6
On 17.02.08 01:13:54, Nicolai Hähnle wrote:
> 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?
Possibly and the - button disabled when there's no selection
in the
buildset view. Though I hope you're aware that all this is
rather
"cosmetic" stuff and we're (read: I am) simply not
yet at the level to
do such things because there's quite a fair bit of "low
level" stuff
thats not there yet.
> > 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.
Exactly. If you look at the kdevelop-devel list archive I
proposed to do
exactly that for cmake projects, unfortunately I didn't yet
have the
time. As you see KDevelop4 is simply not ready for general
use.
> Now, guiding the user to the Configure Project dialog
is very useful,
Thats not what I was going to do. configure() on a cmake
project would
simply present a simple gui to choose a builddir and
possibly set some
cmake options.
> 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.
See above, there's no real interruption of the users flow
here. And we'd
like to keep states out of KDevelop as much as we can
because that
introduces quite a bit of complexity. A few ones are going
to be there
(Editing, Debugging, possibly Building), but that should be
kept at a minimum
> 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.)
As I said, that is an error for just 1 project and IMHO
shouldn't affect
the building of other projects - if possible.
And IMHO a failing cmake run or not running it at all should
be
considered the same as a compile error, except that for not
having it
run at all we can be a bit smarter than just notifying the
user and ask
him for a builddir. We can even think about proposing
<projectdir>/build/ as default for cmake projects.
Andreas
--
Today is what happened to yesterday.
_______________________________________________
kdevelop mailing list
kdevelopkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdev
elop
----- End forwarded message -----
--
You need more time; and you probably always will.
_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel
|