Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Some questions about Indexer and C++ Build Projectsettings

Hi Roman,

 

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

[Mikhail] You can use several ways of specifying the default includes:

1. Using the Managed Build Syntax: you can specify that the given option value is a tool built-in using the "builtIn" attribute of a "listOptionValue" element, e.g.

 

            <option

                  name="Include Paths"

                  command="-I"

                  browseType="directory"

                  valueType="includePath"

                  id="sub.tool.opt.inc.paths">

               <listOptionValue

                     value="/usr/include">

               </listOptionValue>

               <listOptionValue

                     value="/opt/gnome/include">

               </listOptionValue>

               <listOptionValue

                     value="/usr/gnu/include"

                     builtIn="true">

               </listOptionValue>

            </option>

 

2. You can use the CDT scanner discovery profile mechanism to calculate the compiler built-in includes and pre-processor definitions. I'm attaching you an e-mail I posted recently to answer the similar question

 

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?

[Mikhail] See attached mail

 

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?

[Mikhail] You can use an option value handler mechanism for handling this. This mechanism allows ISVs to provide the call-back that will be notified when an option value is changed and do any other necessary modifications. The callback must implement an org.eclipse.cdt.managedbuilder.core.IManagedOptionValueHandler interface and can be specified for the particular option using the "valueHandler" option attribute.

In your case you should implement the call-backs for your "-v" compiler and linker options. When the value, e.g. of your compiler -v option will be modified, your call-back will be fired and you will be able to set the linker -v option to the appropriate value.

One minor note I have to add here is that the option value handler mechanism is a little buggy and inconsistent in CDT 3.0.1, e.g. currently you will be notified for the option value change only after the "apply" or "ok" is pressed, so in case a user changes an option in UI, the value change of an other corresponding option might not be reflected until after you press the apply button. I'm going to work on fixing all the bugs and inconsistencies the next week, so you might need to use the CDT 3.0.2 to take the full advantage of the option value handler functionality.

 

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.  Unfortunately, I haven't

figured out yet, how to do so in the most simple way.

And I don't know how to handle this issue with the

fact that the list of available drivers should be

fetched dynamically (I feel that I need some sort of

provider class here. but how do I attach it at this

option?). For now I hard-coded them in the plugin.xml

as enumeration options. But this is ugly and makes the

plugin.xml very, very long. Has someone better ideas

how to do it better?

[Mikhail] You can not define custom option types, but you are right, you may use the enumerated option types for your case. You may not hard-code all the values, but instead you may use the Option Value Handler mechanism again(see my previous comment). In order to set the option vale dynamically, you may handle the OPEN event (see org.eclipse.cdt.managedbuilder.core.IManagedOptionValueHandler). I suppose this should work.

Does this solution suit your needs?

 

Regards,

Mikhail

 

 

 

           

__________________________________

Yahoo! Music Unlimited

Access over 1 million songs. Try it free.

http://music.yahoo.com/unlimited/

_______________________________________________

cdt-dev mailing list

cdt-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/cdt-dev

--- Begin Message ---
Title: RE: [cdt-dev] Managed Build System Questions

Hi Hugh,

Sorry for the delayed response...

Re #1:
The gnu tool-chain definition uses the CDT scanner discovery profile
mechanism to calculate the gcc built-in includes and pre-processor
definitions.
The scanner discovery profile is an extension point
(id="org.eclipse.cdt.make.core.ScannerConfigurationDiscoveryProfile")
defined in CDT that an ISV can contribute to in order to supply the
mechanism of automatic calculation of the compiler built-ins.

The MBS tool-chain definition can contain the
scannerConfigDiscoveryProfileId attribute that holds the id the
ScannerConfigurationDiscoveryProfile extension that should be used for
that tool-chain.

You could either remove the "scannerConfigDiscoveryProfileId" attribute
for your gnu tool-chain if you do not need this functionality, or
implement the "ScannerConfigurationDiscoveryProfile" extension suitable
for your compiler, and set the "scannerConfigDiscoveryProfileId"
attribute of your tool-chain to the id of that extension.

For more info on how to contribute to the
ScannerConfigurationDiscoveryProfile extension-point, see the
description of that extension-point and its implementation for the Gnu
tool-chain -
"org.eclipse.cdt.managedbuilder.core.GCCManagedMakePerProjectProfile".

Regards,
Mikhail



-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Hugh O'Keeffe
Sent: Tuesday, October 25, 2005 12:35 PM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Managed Build System Questions

I've read the Extensibility document and am currently working on
developing
my own plugin based on org.eclipse.cdt.managedbuilder.gnu.ui_3.0.0. The
plugin is for GNU tools for an embedded target; it has different
executable
names and option switches to the existing CDT supported GNU tools. Some
questions:

1. The Managed Build System automatically adds header files to a new
"Executable GNU" project when I create it using the "Managed C Project"
Wizard. It seems to automatically detect mingw or cygwin headers on my
machine and include them. If I rename the mingw/cygwin directories they
are
not found and not included. Where does this functionality reside ? (I
want
to turn it off as these headers are not relevant for my GNU toolchain).

2. I want to extend the "Managed C Project" Wizard to add a single file
to
all newly created projects (a GNU linker control file for use with the
"-T"
switch). Any ideas as to how to easily do this ?


Thanks in advance,

Hugh,,


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


--- End Message ---

Back to the top