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 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.)
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.
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.? 

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

Back to the top