Each platform is given a three letter name (see the file
doc/pine-ports). Make up a new one for your new port. We've
attempted to bring all potential platform dependencies into the files:
{pico,pine}/osdep/os-xxx.h,
{pico,pine}/osdep/os-xxx.ic,
and {pico,pine}/makefile.xxx, where xxx
is the three letter name of the port. Thus any new port will hopefully
just result in new versions of these files and some notes for the
pine-ports file.
There are separate dependencies in the c-client source, but that
is handled in separate documentation there.
Regrettably, the source code is also full of instances of ifdef DOS.
Most of these are due to memory limit problems on DOS as
opposed to actual system dependencies.
The makefiles are kept as simple and straight-forward as possible, because many previous attempts at automatically figuring out what to do seem to have become complex and ineffective in what they set out to do: which is to make compiling and installing the program easy. Each port is for a specific hardware/software platform, also because past attempts to generalize on versions of Unix or some CPU architecture don't seem to have gained much. Thus, there is a separate makefile for each platform that calls the appropriate compiler and linker with the appropriate flags. Most of these makefiles are pretty similar. The makefile also specifies which of the os-xxx.c and os-xxx.h files to use. It is the root from which most platform dependencies are selected. In most cases the makefile also defines a symbol named after the platform on which there can be dependencies in the source code, though we've tried to minimize relying on this where reasonable. When different "ports" are very similar, it is sometimes possible to use the same pine code (for example) with only a small change in the c-client or pico code. In those cases, that kind of dependency is reflected in the top-level build script. The build script can usually be used to invoke the various makes correctly. It may set some variables before running make so look to see what build does before trying a make in one of the subdirectories. This is especially true if LDAP is being included.
It is almost always easier to start with an existing port when trying to port to a new system. There is a port called gen (generic) which may be a good starting point. On the other hand, if another port is close to what you want, start with it instead.
The file pico/osdep/os-xxx.h contains most of the general
platform dependent #include's and #defines.
There are a number
of Pine configuration settings that are defined in
pine/osdep/os-xxx.h, as well, such as the
place it looks for certain files, defaults for the printer and folder
names, the maximum screen size, and so on.
Start by looking at the generic pico/osdep/os-gen.h file
and comparing it to some of the specific os-xxx.h files there.
The osdep/os-xxx.c files contain functions that are potentially
platform dependent. Again, the idea is to gather all the dependencies in
one place.
We use a complicated looking method to produce
the os-xxx.c files from a set of included files. Each included
file usually contains a single implementation method and we've
found that there are
usually only two or three different methods in the
ports we've done so far. Hopefully, coming up with an os-xxx.c
for a new port will usually be a matter of including the right set of
these already written functions. This is done by writing a new
os-xxx.ic file in the osdep subdirectories.
Starting with the generic os-gen.ic, as you did with
the os-gen.h file above, may be a useful strategy.
We strongly encourage that no changes be made to the general source when porting and that all changes be contained in the system dependent files if possible. The object is to maintain source code integrity and assimilate ports to new platforms rapidly. The more conventional way to do this is with a large collection of #ifdefs. The problem with this is that adding a port for a new platform implies changing the source code for all the other platforms and thereby risks breaking them. (We readily admit that there are still too many ifdefs in the code.)
If you do port Pine to a new platform we hope that you will send us the changes required so that we may attempt to include it in a later release. Thanks!
.pinerc
/usr/local/lib/pine.conf
/usr/local/lib/pine.conf.fixed