From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of djlynott@xxxxxxxxxxxxxxxxxxx
Sent: Thursday, November 01, 2007
1:13 AM
To: lagarcia@xxxxxxxxxx; CDT General developers list.
Cc: CDT
General developers list.; cdt-dev-bounces@xxxxxxxxxxx
Subject: Re: [cdt-dev] Common
toolchain options
Leonardo Augusto Guimarães
Garcia <lagarcia@xxxxxxxxxxxxxxxxxx>
Sent
by: cdt-dev-bounces@xxxxxxxxxxx
10/29/2007 02:09 PM
Please
respond to
lagarcia@xxxxxxxxxx; Please respond to
"CDT General developers list."
<cdt-dev@xxxxxxxxxxx>
|
|
To
|
"CDT General
developers list." <cdt-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
Re: [cdt-dev] Common toolchain options
|
|
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.
[Mikhail] You could use the
optionApplicability mechanism for that purpose. You could specify the
applicability logic aither in Java via the org.eclipse.cdt.managedbuilder.core.IOptionApplicability
call-back specified with the option#applicabilityCalculator attribute or
directly in option definition via option enablement expressions specified via
the “enablement” element. See option element schema for detail.
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).
[Mikhail] There is an extension mechanism
allowing to override the new configuration dialog and the complete manage
config dialog on the build system level. The mechanism does not allow to consomize
that on the tool-chain level. One of the problems for implementing the
tool-chain-based customization is that it is not clear how this should work, e.g.
which “manage config” to use in case project configurations contain
different tool-chains specifying different “manage config”
mechanisms. Another problem is that tool-chain=based customization of the “manage
config” mechanism might be confusing for the users. In any way feel free
to open an enhancement request if you have any ideas/proposals regarding
implementing the tool-chain-based “manage config” mechanism.
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.
[Mikhail] That’s an interesting
suggestion. Could you create an enhancement request regarding this to consider implementing
this?
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?
[Mikhail] Regarding the unimplemented
functionality you are mentioning (i.e. manage config dialog enhancements), there
are no plans for enhancing it as far as I can tell. As I said you could open enhancements
requests but this will not guarantee that anyone from the community will pick
them up in the nearest future. The best way to make the functionality appear in
the CDT is to provide a patch for it. I’ll be glad to discuss/review any
proposals/patches for the “manage config” functionality J
Regards,
Mikhail
P.S. Let me know if I missed some questions
you asked with this thread..
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