Tom Lane writes:
> > Is there some cost of #define __darwin__ in src/template/darwin that
> > I'm not seeing? (not trying to be inflamatory here. :-)
I think that all in all it's okay to #define __darwin__ in
include/port/darwin.h until proven not so, given that there are much worse
hacks in there (e.g. unixware). Putting -D options on the command line is
uglier than sin IMHO.
> I was just reminded of another reason why we like compiler-provided
> symbols of this kind better than hacking one up in the port's header
> file: you don't have to be very careful about whether such a symbol
> is defined yet or not. For example, our config.h has
>
> /*
> * Define this if your operating system supports AF_UNIX family sockets.
> */
> #if !defined(__CYGWIN__) && !defined(__QNX__) && !defined(__BEOS__)
> # define HAVE_UNIX_SOCKETS 1
> #endif
>
> which works fine, but only because those are all compiler-predefined
> symbols --- the port-specific os.h file hasn't been included yet.
> ("Rearrange the code" isn't a very good retort, because that just
> introduces other ordering problems.)
A code reordering of the config.h, c.h, postgres.h chain is definitely
necessary IMO, especially since I'd like to start generating config.h.in
automatically with autoheader when Autoconf 2.50 is out. Then we could
reserve config.h for autoconf-determined "facts", put the "evaluation" of
config.h as necessitated by the PostgreSQL code into c.h, and maybe make
postgres.h backend-specific stuff only. The above statement should really
go into c.h then.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/