Hi Dave,
djlynott@xxxxxxxxxxxxxxxxxxx wrote:
Hi,
djlynott@xxxxxxxxxxxxxxxxxxx
wrote:
I'm trying to add support for a GCC based cross development toolchain
with
CDT 4.0. Many projects I work with are mixed language and have C and
C++
sources. While the current GCC based toolchains support this, they
force
me to enter include paths and other settings separately for each tool.
When developing my plug-in I would like to have a number of options
like
include paths that are shared between tools. Is this possible from a UI
and model perspective (the MBS extensibility document indicates an
option
can have only one tool).
If you would like to share exactly the same option
values
between two options from different tools in the same tool-chain you can
use the IManagedOptionValueHandler interface and valueHandler attribute
of the option element on the buildDefinitions extension-point. This
way,
when the value of one of the options change, you can programmatically
sync
the value of the other option.
While this is an approach, it seems
like CDT should offer this as the default behavior. Many toolsets (Dev
Studio, Dev-C++) make no differentiation between C and C++ projects
regarding
includes and library paths (unique settings are separated out). Another
approach I was going to head down was a common set of options and use
your
valueHandler solution to push these settings to the tool options. The
problems
with this approach are:
1) How do I hide the original
toolchain
options short of developing an entirely separate toolchain. I'd prefer
to "inherit" from the CDT provided GCC toolchain.
AFAIK this is not currently possible. There is an attribute named
"unusedChildren" on tools that was supposed to do that, but it is not
yet implemented.
2) Altering the UI in
this way may confuse
users that switch between my toolchain and the standard CDT toolchains
(i.e. Cygwin, MinGW, etc.)
Since many of the toolchains I want
to support are cross development toolchains, I think the current
"Manage
configurations" dialog is a bit naive at present. It should select
a toolchain and then offer existing and default configurations that
match
the toolchain vs. assume the existing toolchain that is selected for
the
project (or at least allow me to override it in that dialog). I know
our
configurations are quite complex and I think my users are going to want
the ability to import configurations external to a given project as
well.
I'd like to make minimal changes to support the above use-cases or at
least
know that CDT development will align with my needs before expending a
bunch
of work. Are these type of things planned? Are they there already and I
just don't know how to take advantage of them? I could use some
guidance.
Thanks,
-- Dave
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Leonardo Garcia
IDE Software Engineer - Linux on Cell
Linux Technology Center Brazil
Phone: +55-19-2132-2068 (T/L: 839-2068)
lagarcia@xxxxxxxxxx_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|