GNOME Bugzilla – Bug 710519
Portability schmortability
Last modified: 2013-11-20 21:33:17 UTC
There might be more cleanup that can be done (a scan of online manpages of different platforms suggests we probably could get away with requiring SUSv2/UNIX98 support, and possibly even SUSv3/POSIX.1-2001). But this is a start...
Created attachment 257717 [details] [review] Remove alleged support for OS/2 In particular, remove the OS/2 GModule implementation (which AFAICT was never actually built even on OS/2).
Created attachment 257718 [details] [review] Remove alleged support for BeOS Since the initial addition of BeOS support in 1999, there has only been one update to it (in 2005, and it wasn't even very big). GLib is known to not currently build on Haiku (or presumably actual BeOS) without additional patching, and the fact that there isn't a single G_OS_BEOS check in gio/ is suspicious. Additionally, other than the GModule implementation, all of the existing G_OS_BEOS checks are either (a) "G_OS_UNIX || G_OS_BEOS", or (b) random minor POSIXy tweaks (include this header file rather than that one, etc), suggesting that if we were going to support Haiku, it would probably be simpler to treat it as a special kind of G_OS_UNIX (as we do with Mac OS X) rather than as its own completely different thing. So, kill G_OS_BEOS.
Created attachment 257719 [details] [review] Remove alleged support for last-millennium Unixes Remove workarounds for NeXTStep (last released in 1995), SunOS (1994), HP-UX 9.x (1992) and 10.x (1995), OSF/1 / Digital UNIX / Tru64 UNIX 4.x (1999), and AIX 4.x (1999). HP-UX 11 implements dlopen(), so dropping support for earlier versions also lets us remove the HP-UX-specific gmodule-dld.
Created attachment 257720 [details] [review] Require C90 compliance Assume all supported platforms implement C90, and therefore they (correctly) implement atexit(), memmove(), setlocale(), strerror(), and vprintf(), and have <float.h> and <limits.h>. (Also remove the configure check testing that "do ... while (0)" works correctly; the non-do/while-based version of G_STMT_START and G_STMT_END was removed years ago, but the check remained. Also, remove some checks that configure.ac claimed were needed for libcharset, but aren't actually used.) Note that removing the g_memmove() function is not an ABI break even on systems where g_memmove() was previously not a macro, because it was never marked GLIB_AVAILABLE_IN_ALL or listed in glib.symbols, so it would have been glib-internal since 2004.
Created attachment 257721 [details] [review] Require POSIX.1 (1990) compliance on unix Assume unix platforms support the original POSIX.1 standard. Specifically, assume that if G_OS_UNIX, then we have chown(), getcwd(), getgrgid(), getpwuid(), link(), <grp.h>, <pwd.h>, <sys/types.h>, <sys/uio.h>, <sys/wait.h>, and <unistd.h>. Additionally, since all versions of Windows that we care about also have <sys/types.h>, we can remove HAVE_SYS_TYPES_H checks everywhere. Also remove one include of <sys/times.h>, and the corresponding configure check, since the include is not currently needed (and may always have just been a typo for <sys/time.h>).
Created attachment 257722 [details] [review] Replace #ifdef HAVE_UNISTD_H checks with #ifdef G_OS_UNIX In Windows development environments that have it, <unistd.h> is mostly just a wrapper around several other native headers (in particular, <io.h>, which contains read(), close(), etc, and <process.h>, which contains getpid()). But given that some Windows dev environments don't have <unistd.h>, everything that uses those functions on Windows already needed to include the correct Windows header as well, and so there is never any point to including <unistd.h> on Windows. Also, remove some <unistd.h> includes (and a few others) that were unnecessary even on unix.
Review of attachment 257717 [details] [review]: Yes, please
Review of attachment 257718 [details] [review]: I'm all for it
Review of attachment 257719 [details] [review]: seems fine to me
Review of attachment 257720 [details] [review]: I like the sentiment, but the new requirements should probably find their way into our docs. Good candidates for this are INSTALL.in and docs/reference/glib/building.xml
Review of attachment 257721 [details] [review]: Again, this should go into the docs somewhere. The patch like we should document "G_OS_UNIX == POSIX.1" ?
Review of attachment 257722 [details] [review]: dropping the unneeded includes looks like a nice cleanup. Not sure that HAVE_UNISTD_H -> G_IO_UNIX is a huge win, but sure
Created attachment 260313 [details] [review] building: belated docs update: GNU make is required, not recommended
Created attachment 260314 [details] [review] building: Document C90 and POSIX requirements
Review of attachment 260313 [details] [review]: sure
Review of attachment 260314 [details] [review]: ::: INSTALL.in @@ +15,3 @@ +GLib requires a C90-compliant (but not necessarily C99-compliant) C +compiler and libc. On unix-like systems, it also assumes compliance I'm not sure if we use Unix or UNIX capitalization in doc. But I'm sure it is not unix.
Pushed. I may open another bug later for the "--disable-egregious-portability" idea.
(In reply to comment #16) > +GLib requires a C90-compliant (but not necessarily C99-compliant) C > +compiler and libc. On unix-like systems, it also assumes compliance > > I'm not sure if we use Unix or UNIX capitalization in doc. But I'm sure it is > not unix. fixed to "UNIX"