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
