[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
parser and MBS macros, was RE: [cdt-dev] Some questions about Indexer and C++ BuildProjectsettings
|
Just a note, as I am using this too...
I haven't investigated fully yet, but I think the parser gets the raw
text when it asks MBS for the macros, and doesn't get the expanded path.
I'm using the macros already for include paths in the way that you
mention and none of my standard includes seem to get parsed, and I get
warnings in the problems view about bad paths. So beware that parsing
might not quite work right on such headers.
Yet another instance of something I keep meaning to dig into further so
I can post a meaningful Bugzilla report, but keep not getting around to
:-(
___________________________________________
Chris Recoskie
Software Designer
Texas Instruments, Toronto
http://eclipse.org/cdt
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On
> Behalf Of Roman Levenstein
> Sent: Friday, November 25, 2005 7:00 AM
> To: CDT General developers list.
> Subject: RE: [cdt-dev] Some questions about Indexer and C++
> BuildProjectsettings
>
> Hi Mikhail,
>
> 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>
>
> 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?
>
> 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 General developers list."
> > <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
