Re: [cdt-dev] Some questions about Indexer and C++ Build Project setting

[Roman Levenstein <romixlev@xxxxxxxxx>]

Hi Wieant

> 
> > 1) It is possible to define inclcude directories
> paths
> > in the options using special extension points and
> this works. But it is
> > not very convinient for the standard include paths
> of the compiler, since
> > a developer has to enter them every time for each
> new project. I'm pretty
> > sure that it is possible to append these paths to
> the list of include
> > paths automatically. But I cannot find where I
> have to do it. Is there
> > something like IncludePaths provider class that I
> can overload???
> > 
> > 2) Though we use our own compiler, CDT still uses
> GCC
> > for Indexer for some reason. And of course it also
> takes the wrong
> > include files in this case, since standard
> includes for GCC and our
> > compiler are different. So, where is the place or
> what is the method that
> > I can use to tell Indexer about our own standard
> include paths and
> > predefined symbols?
> 
> Have a look at the
>
'org.eclipse.cdt.make.core.ScannerConfigurationDiscoveryProfile'
> extension point. This allows you to specify a
> provider (your compiler) and a console parser to
parse the 
> compiler output providing scanner info like 
> include paths and predefined
> symbols.
 
> In the toolChain element in your buildDefinitions
> extension you can refer
> to that SCDP using the
> 'scannerConfigDiscoveryProfileId' attribute.
> 

  Thanks for the info. I already tried to look into
this,
  but at that time I got the impression that it only
allows for the approach where the compiler is run with
special options that display all include paths and
predefined symbols. The approach is rather universal,
but a bit GCC based. We have our own compiler which
cannot emit the information in this format and cannot
emit some sort of information at all(e.g. include
paths). On the other hand, the paths are known more or
less in advance, e.g. in the form
$COMPILER_HOME/include. Also almost all built-in
symbols are also known in advance. Is it possible to
use this approach with    
ScannerConfigurationDiscoveryProfile and provide the
information "statically", i.e. without calling the
external compiler and parsing its output?
 
> > 3) In the Project Properties/ C++ Build settings I
> > have defined some groups and categories for
> compiler settings, for linker
> > settings, etc. While doing it, I've felt the need
> to have something like
> > "shared options". E.g. I want "-v" (verbose) to
> apply to both compiler
> > and linker. But is it possible to say that one
> option belongs or
> > influences two different groups/categories? I have
> the impression that
> > such a scenario is not covered yet by standard CDT
> functionality, or?
> 
> Just like your "-v" we have several shared tool
> options, the way we fixed
> is to use our own command line generator. When it is
> called to provide the
> command line for a specific tool we check for any
> shared options, and
> append them to the command line. Note that it may be
> a bit tricky to get
> access to the right options from other Tools.
 
  Understood. But may be I'll try first the other
approach proposed by Mikhail using callbacks on Option
value changes. It seems to be easier.
 
> > 4) How can one define new type of option? Or more
> > precisely, a new way to display some options in
> the GUI. I'd like to give
> > a developer the possibility to select a set of
> drivers for our
> > board. Basically, it is a list of selected
> drivers. But I don't want the
> > developer to search through the filesystem for
> them.  Instead, I want to
> > display a list of available drivers (and this set
> can change dynamically,
> > i.e. independent from the plugin) in a nice custom
> GUI form and let the
> > developer do a selection.
>   ...
> 
> I'm not sure if this is possible at the moment, but
> in my opinion would be a great enhancement. The
current set of options
> seems to cover about
> 100%, but there will be situations, like yours, in
> which a custom editor
> would be preferred.
> 
> Bugzilla 68232 refers to a Proposal for the Managed
> Build system.
> This proposal
>
(https://bugs.eclipse.org/bugs/attachment.cgi?id=14860)
> does mention a customEditor field, but I'm not sure
> if that is meant
> for the above.

Very interesting link. Thanks!
  

Regards,
 Roman


		
__________________________________ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free. 
http://music.yahoo.com/unlimited/