[apaku at gmx.de: Re: [PATCH] Build configuration hints]

Sun Feb 17 08:15:32 UTC 2008

Oops, forgot the CC

----- Forwarded message from Andreas Pakulat <apaku at gmx.de> -----

Envelope-to: andreas at localhost
Delivery-date: Sun, 17 Feb 2008 09:14:37 +0100
X-Flags: 0000
X-Authenticated: #15861332
From: Andreas Pakulat <apaku at gmx.de>
To: kdevelop at barney.cs.uni-potsdam.de
Subject: Re: [PATCH] Build configuration hints
Mail-Followup-To: kdevelop at barney.cs.uni-potsdam.de
X-BeenThere: kdevelop at barney.cs.uni-potsdam.de
X-Mailman-Version: 2.1.6
Reply-To: kdevelop at kdevelop.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-request at barney.cs.uni-potsdam.de?subject=unsubscribe>
List-Archive: <https://barney.cs.uni-potsdam.de/mailman/private/kdevelop>
List-Post: <mailto:kdevelop at barney.cs.uni-potsdam.de>
List-Help: <mailto:kdevelop-request at barney.cs.uni-potsdam.de?subject=help>
List-Subscribe: <https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop>, 
	<mailto:kdevelop-request at barney.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
kdevelop at kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop

----- End forwarded message -----

-- 
You need more time; and you probably always will.