Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] How to handle different target platforms in CDT

Hi Raphael,

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Raphael Zulliger
> Sent: Freitag, 15. März 2013 07:23
> To: CDT General developers list.
> Subject: Re: [cdt-dev] How to handle different target platforms in CDT
> 
> Hi Walther
> 
> Thanks for your answer!
> 
> Did I get it right, that your product always only has *one* CDT-toolchain with
> *one* IProjectEnvironmentVariableSupplier, although your customer can choose
> between several toolchains (e.g. gcc 4.5 ARM, gcc 4.7 PPC, ...)? (For this
> mail, I assume that the above is correct.)

In fact, we provide the environment for multiple tool chains per target architecture per platform with a single supplier for all of them. This is then reflected in multiple build configurations. E.g.:

VxWorks Diab compiler for IA
VxWorks GNU compiler for IA
VxWorks Intel compiler for IA
VxWorks Diab compiler for PPC
VxWorks GNU compiler for PPC
...

> I think I see how you switch between different toolchains. (E.g. you CDT
> toolchain uses an EnvVar that points to the compiler, linker, etc. The value
> of this EnvVar is calculated by IProjectEnvironmentVariableSupplier depending
> on the customer toolchain selection). This solves part of my use-case below.

Right, the environment itself only contains all paths to all tool chains for all target architectures of a platform.

> Probably the trickier part is to "change" preprocessor directives, exchange
> certain platform specific .cpp and .asm files and re-trigger the indexer,
> scanner config, etc. Do you have to take care of such things as well? If yes,
> as far as I understand, IProjectEnvironmentVariableSupplier is not of big help
> for doing all these things, is it? Do you additionally use
> CExternalSettingProvider for those? And if you do so, does it work well?
> Especially: don't you have problems with indexer, unwanted rebuilds, etc.?

Preprocessor options are another story. For each build configuration we provide, we again have a data driven approach for these. To provide this to CDT, we use the new ILanguageSettingsProvider API.

The indexer works well, and as we switch off automated builds by default, I am not aware of any unwanted rebuilds (if you mean real build runs, not rebuilding the index).

HTH,

Walter

> Thanks again,
> Raphael
> 
> On 03/13/2013 11:54 AM, Brunauer, Walter wrote:
> > Hi,
> >
> > FWIW, we use IProjectEnvironmentVariableSupplier for our multi-platform
> support solution, which provides the specific environment from the installed
> tool chains per platform. The provision of this environment is done outside
> Eclipse, as the platforms we support use a common CLI environment tool, which
> we have to connect to Eclipse. The advantage of this is, that a vendor does
> not need to know anything about Eclipse, plugins, or CDT APIs, but is able to
> provide the environment for his platform in textual format only.
> >
> > Is this what you are searching for?
> >
> > Walter
> >
> >> -----Original Message-----
> >> From: cdt-dev-bounces@xxxxxxxxxxx
> >> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Raphael Zulliger
> >> Sent: Dienstag, 12. März 2013 07:48
> >> To: CDT General developers list.
> >> Subject: [cdt-dev] How to handle different target platforms in CDT
> >>
> >> Hi
> >>
> >> I have a question related to the handling of different target platforms.
> >> For this discussion, we focus on the CPU types of these "target
> >> platforms": e.g. "Intel 32" vs. "Intel 64" vs. "PowerPC" vs. "ARM Cortex
> A9"
> >> vs. ...
> >>
> >> A possible scenario:
> >> ----------------------------
> >> Take the following as given:
> >>       A CDT based product is shipped along with 4 toolchains:
> >>           - GCC 4.5: powerpc-eabi & arm-eabi
> >>           - GCC 4.7: powerpc-eabi & arm-eabi
> >>       The customer has bought two (similar) pieces of hardware:
> >>           - One using a PowerPC CPU (assume product name: "XYZ PPC")
> >>           - One using an ARM CPU (assume product name: "XYZ ARM")
> >>       A customer has a "C/C++ project" with the following build
> >> configurations:
> >>           - Debug
> >>           - Release
> >>       That "project" runs on both devices, provided that they are
> >> compiled with the right toolchain, compiler directives, compiler flags and
> in worst case:
> >> different files.
> >>
> >> Desired behavior:
> >> -------------------------
> >> I think that the following definition/requirement would make sense in
> >> respect to "ease of use" for our customers:
> >>       - The customer should be able to *explicitly choose* the right
> >> *toolchain
> >> version*: 4.7 vs. 4.8
> >>       - The customer should be able to *explicitly choose* the right
> >> *target
> >> platform*: "XYZ PPC" vs. "XYZ ARM"
> >>       - The customer should *not need choosing* the right *toolchain*:
> >> "gcc powerpc-eabi" vs. "gcc arm-eabi"
> >>
> >> These requirements could end-up like this:
> >>       a) The "toolchain version" can be choosen on a "per configuration"
> >> basis. (I think XLC already does it like that)
> >>       b) The right "toolchain" (powerpc-eabi vs. arm-eabi) should be
> >> selected by the system.
> >>       c) The "target platform" should be selectable by the customer
> >> similar as in Visual studio: Having a drop-down (or similar) next to
> >> the "build configuration" button in the Eclipse toolbar
> >>
> >> Questions:
> >> --------------
> >> Implementing a) and b) should be straight forward. But how could the
> >> "target platform" selector be implemented? Remember, that selecting a
> >> target influences compiler directives, flags, paths (indexer) and
> >> even files exclusions.
> >>       - Are there any existing CDT mechanism that already allow
> >> implementing such a behavior?
> >>       - Are there any open source CDT forks having a similar system
> >> where I could get some ideas/code from?
> >>       - Do you have different approaches/ideas handling different
> >> toolchains, target platforms, etc, which are probably better than
> >> what I suggested and still focus on "easy of use" for our customers?
> >> I'm not aware of any CDT mechanism that provide the desired behavior.
> >> Also I couldn't find anything useful on the net (bugzilla, cdt-dev
> archive).
> >> Hence, this email...
> >>
> >> Possible solution:
> >> ------------------------
> >> So far, our customers need to create "build configurations" for every
> >> possible
> >> combination:
> >>       - GCC 4.5 XYZ ARM Debug
> >>       - GCC 4.5 XYZ ARM Release
> >>       - GCC 4.5 XYZ PPC Debug
> >>       - GCC 4.5 XYZ PPC Release
> >>       - GCC 4.7 XYZ ARM Debug
> >>       - GCC 4.7 XYZ ARM Release
> >>       - GCC 4.7 XYZ PPC Debug
> >>       - GCC 4.7 XYZ PPC Release
> >> IMHO, having something like this does not fulfill the "easy of use"
> >> requirement. Especially not, if you're a dealing with even more
> >> target platform. Let's say 4...
> >>
> >> As already mentioned, I'd prefer a solution similar to that of Visual
> Studio.
> >> One approach could be to automatically modify the current active
> >> build configuration programmatically depending on the target platform
> selection.
> >> That would theoretically solve the issue, but I expect many problems
> >> with this approach... some brainstorming ideas:
> >>       - Need to ensure to properly "rebuild" certain things, but I'd
> >> like to not do a full rebuild
> >>       - I'd like to have a different build output directory, so that
> >> all different builds (e.g. 8 builds in the example above) can coexist
> >> on the hard drive
> >>       - Indexer would need to be re-triggered on the same build
> configuration
> >>       - What if the customer manually changes certain settings (e.g.
> >> compiler directives, etc.) in the property pages
> >>       - ...
> >> I haven't thought in-detail about the drawbacks of such a solution as
> >> I hope that someone comes up with a better approach!
> >>
> >> Thanks,
> >> Raphael
> >> _______________________________________________
> >> 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
> >
> 
> 
> --
> Indel AG
> Raphael Zulliger - Software
> Tuefiwis 26
> CH-8332 Russikon
> Switzerland
> 
> Tel.: +41 44 956 20 00
> www.indel.ch
> 
> ---------------------------------------------------------------------
> iDev replaces IMD as the official IDE for Indel embedded programming.
> http://www.indel.ch/en/news/149-idevnews
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top