[cdt-dev] How to handle different target platforms in CDT

[Raphael Zulliger <zulliger@xxxxxxxx>]

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