--- Begin Message ---
Thanks. Yes, that helps.
The way you "inject" the toolchain via
IProjectEnvironmentVariableSupplier could be a good solution for us too.
Raphael
On 03/15/2013 10:07 AM, Brunauer, Walter wrote:
> 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
> _______________________________________________
> 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
--- End Message ---
