Debugger configurations and KCM

[Andreas Pakulat]

On 13.05.08 08:49:18, Vladimir Prus wrote:
> On Tuesday 13 May 2008 02:21:49 Andreas Pakulat wrote:
> > On 12.05.08 14:52:04, Vladimir Prus wrote:
> > > 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.

I'm talking about (2), our cmake support allows to create multiple
builddirs and choose which one to use.

> > 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?

No, because the projecttargetitem only reflects a target in the
buildsystem, not an actual executable that is created somewhere.
Besides, how would I create two run-configurations for the same target,
just once using the optimized build and once the debug-build (in case I
build both in separate builddirs).

Andreas

-- 
You have the capacity to learn from mistakes.  You'll learn a lot today.