| RE: [cdt-dev] Some questions about Indexer and C++ BuildProjectsettings |
|
Hi Roman, Thanks a lot for your answer! All of your proposals are solving exatctly what I have in mind. I think IManagedOptionValueHandler will solve most of my issues with the shared options and . As for predefined include paths and symbols, I'm not sure which method is better. >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. This is in principle OK. The only concern I have is that it is too static. Can I use variables in the values? E.g. <listOptionValue value="$(COMPILER_HOME)/include" builtIn="true"> </listOptionValue> [Mikhail] Yes, you can use the syntax like this. MBS(Managed Build System)
has a notion of the build macros that you can use. The build macros can be referenced
as ${macro_name} and can be used in any option values that accept strings. In
your case you can provide custom build macro supplier that will calculate the
compiler home path and provide a build macro that will hold that path. After
that you may specify your compiler built-in paths as: <listOptionValue value="${COMPILER_HOME}/include" builtIn="true"> </listOptionValue> Where the “COMPILER_HOME” is the name of your macro. To provide a configuration based macro supplier you should implement
the org.eclipse.cdt.managedbuilder.macros.IConfigurationBuildMacroSupplier interface
and specify the implementer name to the “configurationMacroSupplier”
attribute of your tool-chain. For more info on the build macro functionality, see the bugzilla# 89210 Using the scanner discovery profile has some major advantage over the
MBS options: it is CDT-wide, as opposed to MBS options. I mean that in case
your intention is to use only the managed project functionality, using MBS option
built-ins will suit you, but if you are planning to use the standard make projects
for your compiler as well, MBS options will not help you in this case, but for
the standard make projects you can specify the scanner discovery profile (open
the “C/C++ Make Project” property page for the standard make
project -> “Discovery Options” tab -> the “Discovery
Profile:” list contains all available profiles that you can choose for
your project). Also note that in case you specify for your MBS tool-chain both the discovery
profile and MBS option built-ins, the option built-ins will be ignored. I need it because the plugin does not know about the absolute paths to the compiler installation directory. If it does not work, I'll try to use the CDT scanner discovery profile mechanism. But this will be probably more difficult. BTW, are builtIn options displayed to the developer in the corresponding C++ Build settings? Or are they hidden and only used by Managed Make internally? [Mikhail] They should not be displayed, neither will they appear in the
command line. They are used only to provide the build information to the rest
of the CDT. Regards, Mikhail Thanks again! Regards, Roman --- "Sennikovsky, Mikhail" <mikhail.sennikovsky@xxxxxxxxx> wrote: > 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 > === message truncated ===> Subject: RE: [cdt-dev] Managed Build System > Questions > Date: Thu, 10 Nov 2005 20:57:27 +0300 > From: "Sennikovsky, Mikhail" > <mikhail.sennikovsky@xxxxxxxxx> > To: " > <cdt-dev@xxxxxxxxxxx> > > 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 > > _______________________________________________ > cdt-dev mailing list > cdt-dev@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/cdt-dev > __________________________________ 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 |