>It's not a fetish if you have ever ported legacy code that was not written with portability in mind.
This.
You can code portably and take advantage of platform-specific features or performance advantages.
I used to work on a product line that supported dozens of different UNIX platforms (and, eventually, even DOS protected-mode). The entire build process was portable. We had a primary configuration file for code/libraries and one for server internals that provided for:
. shared memory configuration (if any) and other limits
. BSD sockets vs System V streams
. byte-swapped vs regular processors and little- vs big-endian
. 16- vs 32-bit processors (later 64 bit)
. RISC vs CISC
. vagaries of C compilers, normal flags to pass for optimization, gcc vs cc, static vs dynamic links, libraries etc
. INT / LONG bytecounts, floating point, etc.
. ... and many others.
The goal was to abstract everything possible and have platform-specific code limited to the configuration files. Then, porting becomes fine tuning the configuration files, adding platform specific code to the mainline (with appropriate DEFINES) only when absolutely necessary, test, finalize configuration, test again, post the final config files and any changes back to the mainline.
This.
You can code portably and take advantage of platform-specific features or performance advantages.
I used to work on a product line that supported dozens of different UNIX platforms (and, eventually, even DOS protected-mode). The entire build process was portable. We had a primary configuration file for code/libraries and one for server internals that provided for:
. shared memory configuration (if any) and other limits
. BSD sockets vs System V streams
. byte-swapped vs regular processors and little- vs big-endian
. 16- vs 32-bit processors (later 64 bit)
. RISC vs CISC
. vagaries of C compilers, normal flags to pass for optimization, gcc vs cc, static vs dynamic links, libraries etc
. INT / LONG bytecounts, floating point, etc.
. ... and many others.
The goal was to abstract everything possible and have platform-specific code limited to the configuration files. Then, porting becomes fine tuning the configuration files, adding platform specific code to the mainline (with appropriate DEFINES) only when absolutely necessary, test, finalize configuration, test again, post the final config files and any changes back to the mainline.