diff options
author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-05-06 01:46:30 +0000 |
---|---|---|
committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-05-06 01:46:30 +0000 |
commit | b5896ba9f6047e7031e2bdee0622d543e11a6734 (patch) | |
tree | fd7b460593a2fee1be579bec5697e6d887ea3421 /PORTING | |
parent | Initial commit. (diff) | |
download | postfix-upstream.tar.xz postfix-upstream.zip |
Adding upstream version 3.4.23.upstream/3.4.23upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'PORTING')
-rw-r--r-- | PORTING | 24 |
1 files changed, 24 insertions, 0 deletions
@@ -0,0 +1,24 @@ +In order to port software to a new platform: + +- Choose a SYSTEMTYPE name for the new system. You must use a name +that includes at least the major version of the operating system +(such as SUNOS4 or LINUX2), so that different releases of the same +system can be supported without confusion. + +- Add a case statement to the "makedefs" shell script in the source +code top-level directory that recognizes the new system reliably, +and that emits the right system-specific information. Be sure to +make the code robust against user PATH settings; if the system +offers multiple UNIX flavors (e.g. BSD and SYSV) be sure to build +for the native flavor, instead of the emulated one. + +- Add an "#ifdef SYSTEMTYPE" section to the central util/sys_defs.h +include file. You may have to invent new feature macro names. +Please choose sensible feature macro names such as HAS_DBM or +FIONREAD_IN_SYS_FILIO_H. + +I strongly recommend against using "#ifdef SYSTEMTYPE" in individual +source files. While this may look like the quickest solution, it +will create a mess when newer versions of the same SYSTEMTYPE need +to be supported. You're likely to end up placing "#ifdef" sections +all over the source code again. |