[fpc-devel] Portability Standards

[DrDiettrich]

Jonas Maebe wrote:
> 
> On 6 jan 2005, at 22:21, DrDiettrich wrote:
> 
> >> The FPC baseunix/unix units mimic more or less the POSIX standard
> >
> > As already mentioned, I couldn't find these units :-(
> 
> They only exist for unix-like OS'es. They are not generic units which
> you can use to port software from *nix to Dos/Windows (although in
> theory they should compile on Windows with a POSIX-compliant libc
> installed, if some small include files with type definitions are made).

In a port from C to Pascal it's required to implement the OS specific
procedures for all targets, as far as possible. This requires knowledge
of the available target specific procedures, that can be used on the
various platforms. In most cases the C code is written for Unix/POSIX,
so that only a connection to e.g. Windows must be implemented, somehow.
In other cases, like Abbrevia, the Unix connection must be implemented,
and that's when I need detailed information about the available FPC
libraries, even if I'm working on Windows.


In my discussion with Linux people, about the distribution of
FSF/GNU/open source... code, I had an idea for a more practical system
for writing and distributing portable code. My ideas were not understood
by the C people, perhaps I'll find a less biased audience here?

Most readers will know the procedures used to install portable C code on
e.g. Linux, from a *.src.tar.gz or like that. The most critical step is
./configure, where the package tries to find out all required
information about the host and target system. IMO it's not a good idea
to leave it to every single package to implement these tests. In the
case of C code it would be much simpler to support an set of common
header files, containing all ported data types and procedure prototypes.
These header files map the portable functions to the functions available
on the actual target, provide defines for the available functionality
(memory mapped files just come into mind). These header files can be
distinct from the header files of the platform and compiler, they only
have to provide the appropriate mapping to the available procedures. The
difference from the actual automake... procedure is the simplified
maintenance of these header files, required exactly once for every
target OS. Then not much is left what configure or the author can or
should do at all. The makefiles can use platform specific macros for
e.g. producing shared libraries, making libtool superfluous.

The only decisions, left to the author of portable software, are about
the workarounds when a feature, like MM files, is not available on a
platform. In the simple case a Make will fail with unresolved external
symbols, in the more elaborated case the code will check for the
availability of a feature, and use standard procedures on less
comfortably equipped platforms instead.

Even if the exact procedures are somewhat different for C and Pascal,
e.g. the standard header files correspond to Pascal units, the idea IMO
already is part of FPC. What remains to do is the creation and
maintenance of further portable units, in addition to (or extending) the
already existing portable System, Classes, SysUtils etc. units.


Wouldn't it be great to demonstrate to the C world how easy it can be to
write portable software, based on the FPC philosophy? Not that I want to
convince anybody to use Pascal instead of C, but I dream of open source
code that compiles and runs on every (supported) platform, without
autobloat and all that can of worms :-)

I even would accept that Windows is not an official supported platform,
because then I would maintain the portable units for that target myself.
That wouldn't be really hard to do, it only were required to check the
changes to the portable header files or units (interface sections), and
to implement the new or changed funcionality as appropriate for Windows.
Nothing more would be required, to turn Windows or any other best-hated
<g> OS into a supported platform for really portable code ;-)

DoDi