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