[
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,
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
