runpreferences & kconfig question

[Vladimir Prus]

On Monday 08 December 2008 00:36:42 Andreas Pakulat wrote:
> On 07.12.08 21:50:22, Vladimir Prus wrote:
> > On Sunday 07 December 2008 20:27:23 Andreas Pakulat wrote:
> > > On 07.12.08 16:33:08, Vladimir Prus wrote:
> > > > 2. I don't see runconfig.kcfg anywhere -- did you commit it?
> > > 
> > > Well, there's not much point to have it, if its not used for generating the
> > > code.
> > 
> > Then, at least the text in runconfig.h saying it's generated by kconfig_compiler
> > has to be removed.
> 
> Sure.
>  
> > > > 3. Did you have any specific plan how to clean this up? I'm thinking
> > > > that we can create LaunchConfigSkeleton class, derived from
> > > > ProjectConfigSkeleton and specify that inside runconfig.kcfg. Any reason
> > > > that would not work?
> > > 
> > > I don't see why the launch config would need to be project-specific. Sure
> > > at some point we want to have the ability of moving settings into the
> > > project, 
> > 
> > Yes. Or rather, storing launch configs in project so that they are visible
> > to other developers. 
> 
> Not sure what the difference would be, actually right now there's no way to
> share anything of a project except whats written into the .kdev4 file
> during project creation. I'm not sure we can tackle that for 4.0, as it
> might get kinda complex to do properly (we had something like that when I
> started to work on kdev4 about 2 years ago and it was rather complex code
> and almost non-understandable GUI behaviour).

I'll be happy with not implementing this for 4.0 (if that actually proves hard),
in which case the LaunchConfigSkeleton won't be related to ProjectConfigSkeleton.

> > > but generally run-settings should be global - IMHO (think of 
> > > sharing executables across projects)
> > 
> > I was thinking of having hierarchy of launch configs, where you have 'Global'
> > item on the top, and can edit some properties (like default name of debugger),
> > then you have global launch configs, and projects as children of that
> > item. Then you can have project launch configs. Imagine you have a large project
> > with many targets and the project is for ARM GNU/Linux. It would be nice to specify
> > the 'arm-none-linux-gnueabi-gdb' in a single place -- not for each binary in that
> > project.
> 
> So we'd have
> 
> Global
>  - launchconfig1
>  - launchconfig2
>     - slightlydifferent for project foo
>     - slightlydifferent for project bar

Rather

 Global
  - launchconfig1
  - launchconfig2
  - project foo
	- projectlaunchconfig1
	- projectlaunchconfig2

> ? With settings on each level of the tree? How do we provide different
> config pages for pdb or irb (ruby/python)? 

Each launch config has a type. E.g "Python Application". Each launch config
further specifies what config pages it wants -- and Python Application will
specify the pdb config page as desired

> What about remote vs. local gdb, 
> will that stay in the same configuration?

"remote"/"local" means N different things:

   - you run gdb remotely. This is, for most purposes, the same as native run.
   - you run gdb against gdbserver running on remote host. This is a special
   launch type, e.g "C/C++ remote debugging (gdbserver)"
   - you run gdb against custom stub on remote embedded board. This is 
   "C/C++ remote debugging (embedded)" launch type.

- Volodya




> 
> Andreas
>