Debugger configurations and KCM

[Andreas Pakulat]

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. However this doesn't work all that well
for qmake or automake (not to mention custom makefiles). 

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?

Andreas

-- 
You will be surrounded by luxury.