From b5896ba9f6047e7031e2bdee0622d543e11a6734 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Mon, 6 May 2024 03:46:30 +0200 Subject: Adding upstream version 3.4.23. Signed-off-by: Daniel Baumann --- PORTING | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 PORTING (limited to 'PORTING') diff --git a/PORTING b/PORTING new file mode 100644 index 0000000..7a2d503 --- /dev/null +++ b/PORTING @@ -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. -- cgit v1.2.3