The difference between rebuilding and porting
|
Back to Porting engineer |
Table of content
|
Definitions Many times porting is confused with "just rebuilding" a product on another site. Rebuilding suppose that you use the same tool chain and you aim at the same target platform as the original build. If any of these two is not valid then you are actually doing a porting work. "Rebuilding" that turns out to be porting is often the case when some product is build at a remote development site (where the original tool chain and/or the original target hardware are not available). |
Why is it important
to know the difference?
Because confusing rebuilding and porting may result is large software development delays. And the confusion is easy to make, unfortunately. For example, many developers ignore that the target platform has also a software part: usually some libraries and headers shipped with the tool chain. This software part of the target platform is sometimes called "Platform SDK" and sometimes, less clear, "system libraries". One and the same hardware of the target but a change in this software part it's enough to make a different target platform. When working on a code base that is quite mature, meaning that the C/C++ source code was already exposed to a lot of target platforms, the bulk of the porting work is about changing build descriptions not source code (what ever your build system is). The amount of work needed may vary but it is not very much different if there is only 1 digit/letter difference in the target platforms names compared to when there are more visible differences in those names. |
Examples pitfalls
There are several embedded Operating Systems that frequently generate confusions between rebuilding and porting. I've selected two examples. |
Microsoft Windows CE/Mobile platformsWindows CE (and its spin-off Windows Mobile) is not one target platform but a myriad of target platforms. There is actually a Platform Builder tool from Microsoft that makes it easy to change what in include in your target system. There are several aspects to Windows CE platform differences:
Making an estimation error can be very costly. For example the SmartPhone Platform SDKs are not supporting the MS MFC framework and the others do support it. If you expected to "rebuild" your GUI-intensive application that was using MFC for SmartPhone you may be faced with an ugly surprise: you have to completely rewrite your application. Windows Mobile introduced a new dimension and a whole set of new confusions. Windows Mobile is basically a new Platform SDK for the older Windows CE (the heir of the Smart Phone Platform SDK line). But it comes with it's own version numbering and that puzzles everybody. For example Windows Mobile 6 is based on Windows CE 5, not on Windows CE 6, even if Windows CE 6 is commercially available at the same time as Windows Mobile 6. The ways of Microsoft marketing are not for the mere mortal understanding. |
Symbian OS platformsSymbian developer community and in particular Nokia's Series 60 community are very active. New versions of their platform SDKs are coming out at fast pace. Symbian doesn't deliver their own tool chain with the Symbian SDK. Nokia did and does deliver some tool chains with their S60 SDK. It is good to know that, in practice, Symbian is about two kinds of target platforms (and, by way of consequence, several Nokia platforms):
|
Back to Porting engineer |