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