The difference between rebuilding and porting

 

Back to Porting engineer
Back to SBuild manual home

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).

Back to top

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.

Back to top

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 platforms

Windows 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:

  • there are different microprocessors. This is the easy part that everyone understands.
  • there are Platforms SDKs. This is the tricky part that fools everybody. There are three families of platform SDKs. Some are shipped with a toolchain, some are separate installers. And customers and hardware OEMs can create even more using the MS Platform Builder tool.
    • MS Standard Platform SDKs (4.0, 4.2, 5.0, etc.)
    • PoketPC Platform SDKs (2000, 2003, 2005, etc.)
    • Smart Phone Platform SDKs (2003, etc.)
  • there are three tool chains delivered by MS to support Win CE builds (incompatible at the level of their native build descriptions but also in the set of Platform SDKs supported although there is some overlap).
    • Embedded Visual C++ 3 (free but today obsolete)
    • Embedded Visual C++ 4 (still working fine for many current Win CE/Mobile platforms and free even for commercial usage)
    • Visual Studio 2005/2008 (Microsoft preferred way, most up-to-date compilers, but expensive for commercial usage)

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.

Back to top

Symbian OS platforms

Symbian 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):

  • the hardware device(s)
  • the MS Windows PC simulator(s)
Weird enough, these platform happen to be served by disjoint sets of tool chains (Microsoft compilers and Metrowerks compilers for PC simulator and GNU and RVCT for those many ARM-based devices). Both the tool chains supported and the definition of the target platform evolve fast (see the evolution of the S60 SDKs). The situation is so fluid that it is a safer bet to simply assume that a build for Symbian at another development site and/or after a few months is actually a porting effort (may be a quick porting but still a porting). 

Back to top

Back to Porting engineer
Back to SBuild manual home