[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: parser and MBS macros, was RE: [cdt-dev] Some questions about Indexer and C++BuildProjectsettings
|
Er, that should read "when it asks MBS for the include paths".
___________________________________________
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 Recoskie, Chris
> Sent: Friday, November 25, 2005 11:40 AM
> To: CDT General developers list.
> Subject: 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
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
