Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Common toolchain options

Hi Dave,

 

See my answers embedded below.

 

Regards,

Mikhail

 

 


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

--------------------------------------------------------------------
Closed Joint Stock Company Intel A/O
Registered legal address: 125252, Moscow, Russian Federation, 
Chapayevsky Per, 14.

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Back to the top