Debugger configurations and KCM

Vladimir Prus ghost at cs.msu.su
Tue May 13 04:49:18 UTC 2008


On Tuesday 13 May 2008 02:21:49 Andreas Pakulat wrote:
> On 12.05.08 14:52:04, Vladimir Prus wrote:
> > On Monday 12 May 2008 14:11:37 Andreas Pakulat wrote:
> > > On 09.05.08 02:09:50, Vladimir Prus wrote:
> > > > 
> > > > Hi,
> > > > right now the project configuration dialog is KSettings::Dialog. I
> > > > would like to implement "launch configurations" where each project
> > > > can have several configurations, and for each configuration we have
> > > > several pages -- application, general GDB settings, maybe specific
> > > > gdb settings, maybe valgrind settings, so on.
> > > > 
> > > > So, instead of letting KSettings::Dialog load KCM pages, I need to
> > > > have top-level configuration name selector, and based on selected
> > > > configuration, show a specific set of pages. Am I right that KSettings::Dialog
> > > > and KCModule are basically of no help here?
> > > 
> > > We just had a bugreport about kdev3 run stuff and its inconvenience
> > > when running debug and optimized versions of your app. I'm wondering
> > > wether anybody thought about that yet? In particular I hope we will
> > > allow not only specifying executables, but also just picking targets
> > > from the project tree to execute. In that case there needs to be a way
> > > to define which builddirectory should be used to find the executable
> > > from the target and then deduce the actual executable file with that
> > > information.
> > > 
> > > So when creating a debug run configuration you specify target "kdevelop"
> > > and the debug-builddir and then you can just copy that configuration and
> > > s/debug-builddir/release-builddir/ and be done.
> > > 
> > > Just something to consider I think.
> > 
> > I think we definitely need a wait to link executable in launch configuration
> > with a target in build system. I was thinking about "target" selector
> > together with "build automatically" checkbox.
> > 
> > However, I don't have a plan about debug/release. Should launch configuration
> > be hard-bound to "debug"/"release" variant, or just refer to a name of the
> > target and grab whatever build variant happens to be "current"? Do we even
> > have "current build variant" for a project?
> 
> No, we only have a way to fetch the builddir for a given project item
> (and thus for a given target). So we have the "current" thing right now.
> However cmake already supports having different builddirectories for
> each project and stores that. 

Do you mean that:
(1) CMake-the-build-tool has special support for variant builds, different
from creating N build directories and configuring in those directories
separately, or
(2) CMake support supports that.

> However this doesn't work all that well 
> for qmake or automake (not to mention custom makefiles). 

Well, the manual way will still work for custom makefiles; we "only"
need to teach our build systems code, if it does not support that
already.

> So maybe we should introduce buildConfigurations in the API and some
> build-system-dependant way of defining how a build-config (probably a
> user-defineable string) matches to a specific builddir or list of
> qmake-CONFIG-flags or whatever else.
> 
> Then the BuildSystemManager class can translate a
> targetitem+configuration-name into an actual executable:
> 
> KUrl executable(ProjectTargetItem*, const QString& configuration) const;
> 
> How does that sound?

I'm not sure part about user-defined configuration name. For example, 
I plan to add support for Boost.Build, where you can pass a set of properties
on each invocation (say variant=release link=static) and the necessary build
directories will be created automatically. That is, there's no need to
create user-defined configurations and map them to build system's flags. On
the other hand, user-defined configuration can save work if user wishes to 
often change several build-system-level properties at once.

Anyway, why the launch framework has to know about configurations? Cannot
it just know ProjectTargetItem, and ProjectTargetItem know its current
configuration?

- Volodya




More information about the KDevelop-devel mailing list