NON_POSIX_SOURCE

[Simon Marlow]

Folks,

Julian & I had discussed the NON_POSIX_SOURCE situation yesterday and
came to the conclusion that the current situation is unworkable.

Ok, currently what happens is that in Stg.h we #define _POSIX_C_SOURCE,
which means that all RTS sources and via-C compilations are compiled
with this symbol, which on most systems causes the header files to only
bring into scope those features defined by POSIX.  So far so good, this
helps us write portable software by getting the compiler to complain
when we use non-POSIX features.

For those source files which use non-POSIX features (there are
necessarily some: eg. sockets, interval timers, and certain features
used by the Time library are non-POSIX), we define the symbol
NON_POSIX_SOURCE which causes Stg.h to refrain from definining
_POSIX_C_SOURCE.

Now, here's the problem: when we inline a Haskell function across a
module boundary, and the module it comes from was compiled with
NON_POSIX_SOURCE, we must also define that symbol when compiling the
current module.  The only mechanism we have to do this at the moment is
the extra_cc_opts in the package spec, which would mean that we
essentially define NON_POSIX_SOURCE for everything (because the std
package needs it).

The whole idea of using the _POSIX_C_SOURCE thing some of the time
creates other problems too:=20

  - you're not allowed to #include anything before Stg.h.
  - if you preprocess your source with hsc2hs then you have
    to use the same POSIX setting when compiling it as when
    preprocesing it.
  - the configure script detects a different set of feastures
    from those that are actually available most of the time.

So I'm suggesting we forget about #defining _POSIX_C_SOURCE, at least
for via-C compilations.  We can still use it when compiling the parts of
the RTS and libraries which are POSIX-compliant.  It should be ok to
#include Stg.h regardless of whether _POSIX_C_SOURCE is or is not
defined.

Any thoughts?

Cheers,
	Simon