Hi,

On 2011-01-29 I proposed to document the "reasonable portability targets"
supported by gnulib [1]. The same question is popping up again [2][3].
The replies to [1] were:
  - Paul suggested less strict categorization.
  - Simon suggested not to exclude any system, through harsh words.
    Well, actually that was one of the points of the exercise: to make
    it clear that we can't commit to support niche and museum platforms.

I've tried to integrate the comments like this.

[1] http://lists.gnu.org/archive/html/bug-gnulib/2011-01/msg00542.html
[2] http://lists.gnu.org/archive/html/bug-gnulib/2011-05/msg00246.html
[3] http://lists.gnu.org/archive/html/bug-gnulib/2011-05/msg00324.html


2011-05-16  Bruno Haible  <br...@clisp.org>

        doc: List the target platforms.
        * doc/gnulib-intro.texi (Target Platforms): New section.
        * doc/gnulib.texi (Introduction): Update menu.
        * README (Portability guidelines): Refer to the new section. Update
        statement about oldest supported environment. Remove rationale why
        <errno.h>, <string.h>, <stdlib.h> are assumed. Update example of an
        unportable C89 function.
        Reported by Bastien Roucariès <roucaries.bast...@gmail.com> and
        Charles Wilson <cyg...@cwilson.fastmail.fm>. Feedback from Paul Eggert.

--- README.orig Tue May 17 00:23:00 2011
+++ README      Mon May 16 22:50:35 2011
@@ -77,6 +77,7 @@
 
 Contributing to Gnulib
 ======================
+
 All software here is copyrighted by the Free Software Foundation - you need
 to have filled out an assignment form for a project that uses the
 module for that contribution to be accepted here.
@@ -201,7 +202,8 @@
 ----------------------
 
 Gnulib code is intended to be portable to a wide variety of platforms,
-not just GNU platforms.
+not just GNU platforms.  See the documentation section "Target Platforms"
+for details.
 
 Many Gnulib modules exist so that applications need not worry about
 undesirable variability in implementations.  For example, an
@@ -210,27 +212,17 @@
 need not worry about localtime_r returning int (not char *) on some
 platforms that predate POSIX 1003.1-2001.
 
-Originally much of the Gnulib code was portable to ancient hosts like
-4.2BSD, but it is a maintenance hassle to maintain compatibility with
-unused hosts, so currently we assume at least a freestanding C89
-compiler, possibly operating with a C library that predates C89.  The
-oldest environment currently ported to is probably SunOS 4 + GCC 1.x,
-though we haven't tested this exact combination.  SunOS 4 last shipped
-on 1998-09-30, and Sun dropped support for it on 2003-10-01, so at
-some point we may start assuming a C89 library as well.
+Currently we assume at least a freestanding C89 compiler, possibly
+operating with a C library that predates C89.  The oldest environment
+currently ported to are probably HP-UX 10.20 and IRIX 5.3, though we
+are not testing these platform very often.
 
 Because we assume a freestanding C89 compiler, Gnulib code can include
 <float.h>, <limits.h>, <stdarg.h>, and <stddef.h> unconditionally.  It
 can also assume the existence of <ctime.h>, <errno.h>, <fcntl.h>,
-<locale.h>, <signal.h>, <stdio.h>, <stdlib.h>, <string.h>, and
-<time.h>.  Some of these headers, such as <errno.h>, were present in
-Unix Version 7 and are thus widely available.  <string.h> and
-<stdlib.h> were not in Unix Version 7, so they weren't universally
-available on ancient hosts, but they are both in SunOS 4 (the oldest
-platform still in relatively-common use) so Gnulib assumes them now.
-Similarly, many modules include <sys/types.h> even though it's not
-even in C99; that's OK since <sys/types.h> has been around nearly
-forever.
+<locale.h>, <signal.h>, <stdio.h>, <stdlib.h>, <string.h>, and <time.h>.
+Similarly, many modules include <sys/types.h> even though it's not even
+in C99; that's OK since <sys/types.h> has been around nearly forever.
 
 Even if the include files exist, they may not conform to C89.
 However, GCC has a "fixincludes" script that attempts to fix most
@@ -239,10 +231,10 @@
 should use fixincludes or fix their include files manually.
 
 Even if the include files conform to C89, the library itself may not.
-For example, SunOS 4's (free (NULL)) can dump core, so Gnulib code
-must avoid freeing a null pointer, even though C89 allows it.
+For example, strtod and mktime have some bugs on some platforms.
 You can work around some of these problems by requiring the relevant
-modules, e.g., the Gnulib 'free' module supplies a conforming 'free'.
+modules, e.g., the Gnulib 'mktime' module supplies a working and
+conforming 'mktime'.
 
 The GNU coding standards allow one departure from strict C99: Gnulib
 code can assume that standard internal types like size_t are no wider
--- doc/gnulib-intro.texi.orig  Tue May 17 00:23:00 2011
+++ doc/gnulib-intro.texi       Tue May 17 00:22:57 2011
@@ -74,6 +74,116 @@
 stdout if desired, and emits an error message if the subprocess
 failed.
 
+@node Target Platforms
+@section Target Platforms
+
+Gnulib supports a number of platforms that we call the ``reasonable
+portability targets''.  This class consists of widespread operating systems,
+for three years after their last availability, or --- for proprietary
+operating systems --- as long as the vendor provides commercial support for
+it.  Already existing Gnulib code for older operating systems is usually
+left in place for longer than these three years.  So it comes that programs
+that use Gnulib run pretty well also on these older operating systems.
+
+Some operating systems are not very widespread, but are Free Software and
+are actively developed.  Such platforms are also supported by Gnulib, if
+that OS's developers community keeps in touch with the Gnulib developers,
+by providing bug reports, analyses, or patches.  For such platforms, Gnulib
+will not support all versions that are at most three years old, but only
+the versions of the last year or the last few months, depending on the
+maturity of said OS project, the number of its users, and how often these
+users upgrade.
+
+Niche operating systems are generally unsupported by Gnulib, unless some
+people from their developers or users community contributes support to
+Gnulib.
+
+The degree of support Gnulib guarantees for a platform depends on the
+amount of testing it gets from volunteers.  Platforms on which Gnulib
+is frequently tested are the best supported.  Then come platforms with
+occasional testing, then platforms which are rarely tested.  Usually,
+we fix bugs when they are reported.  Except that some rarely tested
+platforms are also low priority; bug fixes for these platforms can
+take longer.
+
+As of 2011, the list of supported platforms is the following:
+
+@itemize
+@item
+glibc systems.  With glibc 2.8 or newer, they are frequenty tested.  With
+glibc 2.3 or newer, they are occasionally tested.
+@item
+MacOS X.  In versions 10.5 and 10.6, it's frequently tested.  In version
+10.4, it's rarely tested.
+@item
+FreeBSD 6.0 or newer is occasionally tested.  FreeBSD 5.x is rarely tested.
+@item
+NetBSD 5.0 or newer is occasionally tested.  NetBSD 3.0 or newer is rarely
+tested.
+@item
+OpenBSD 4.0 or newer is occasionally tested.  OpenBSD 3.8 or newer is rarely
+tested.
+@item
+AIX 6.1 or newer is occasionally tested.  AIX 5.1 or newer is rarely tested.
+@item
+HP-UX 11.11 or newer is occasionally tested.  HP-UX 11.00 is rarely tested.
+HP-UX 10.20 is rarely tested and low priority.
+@item
+IRIX 6.5 is occasionally tested.  IRIX 5.3 is rarely tested and low priority.
+@item
+OSF/1 5.1 is occasionally tested.  OSF/1 4.0 is rarely tested and low
+priority.
+@item
+Solaris 8 and newer are occasionally tested.  Solaris 7 is rarely tested.
+Solaris 2.6 and older is rarely tested and low priority.
+@item
+Cygwin 1.7.x is frequently tested.  Cygwin 1.5.x is occasionally tested.
+@item
+mingw is frequently tested.  But note that some modules are currently
+unsupported on mingw: @code{mgetgroups}, @code{getugroups}, @code{idcache},
+@code{userspec}, @code{openpty}, @code{login_tty}, @code{forkpty},
+@code{pt_chown}, @code{grantpt}, @code{pty}, @code{savewd},
+@code{mkancesdirs}, @code{mkdir-p}, @code{euidaccess}, @code{faccessat}.
+The versions of Windows that are supported are Windows XP and newer.
+@item
+Native Windows, with MSVC as compiler, is not tested and low priority.
+@item
+mingw in 64-bit mode is not tested and low priority so far.
+@item
+Interix 3.5 is not tested.
+@item
+Haiku is rarely tested, BeOS is not tested and low priority.
+@item
+uClibc on Linux is rarely tested.
+@item
+QNX is not tested and low priority.
+@end itemize
+
+These operating systems are all supported in an unvirtualized environment.
+When you run an OS inside a virtual machine, you have to be aware that the
+virtual machine can bring in bugs of its own.  For example, floating-point
+operations on Solaris can behave slightly differently in QEMU than on real
+hardware.  And Haiku's @command{bash} program misbehaves in VirtualBox 3,
+whereas it behaves fine in VirtualBox 4.
+
+Similarly, running native Windows binaries on GNU/Linux under WINE is
+rarely tested and low priority: WINE has a set of behaviours and bugs that
+is slightly different from native Windows.
+
+The following platforms are @emph{not} supported by Gnulib.  Even correct
+patches for their support will not be applied.
+
+@itemize
+@item
+Windows 95/98/ME.
+@item
+DJGPP and EMX (the 32-bit operating systems running in DOS).
+@item
+MSDOS (the 16-bit operating system).
+@item
+Windows Mobile, Symbian OS, iOS.
+@end itemize
+
 @node Modules
 @section Modules
 
--- doc/gnulib.texi.orig        Tue May 17 00:23:00 2011
+++ doc/gnulib.texi     Mon May 16 22:50:35 2011
@@ -108,6 +108,7 @@
 * Benefits::
 * Library vs Reusable Code::
 * Portability and Application Code::
+* Target Platforms::
 * Modules::
 * Various Kinds of Modules::
 * Collaborative Development::


-- 
In memoriam The victims of the Zaklopača massacre 
<http://greatersurbiton.wordpress.com/2010/02/12/interview-with-nihada-hodzic-survivor-of-the-zaklopaca-massacre/>

Reply via email to