Skip site navigation (1) Skip section navigation (2)

Re: darwin pgsql patches

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Bierman <bierman(at)apple(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: darwin pgsql patches
Date: 2000-12-02 17:30:54
Message-ID: 16592.975778254@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Peter Bierman <bierman(at)apple(dot)com> writes:
> But I don't actually think it should. It's the prupose of configure,
> not the compiler, to determine the system that's running. Why should
> the compiler care what varriant of an OS it's running on? It might not
> even be compiling code for that OS.

Yeah, but header files care, and predefined symbols are the only way
that the C compiler can pass what it knows about the target environment
(which it *must* know about, in some fashion) to header files.
To take one example, what if a header file needs to know whether it's
being compiled under Rhapsody or Darwin?

> Is there some cost of #define __darwin__ in src/template/darwin that
> I'm not seeing? (not trying to be inflamatory here. :-)

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.)

You might want to think about having the template/darwin file add
-D__darwin__ to CPPFLAGS, instead of putting a #define in port/darwin.h.
And have another go at convincing Apple that they're wrong not to have
their compiler provide such a symbol automatically.

			regards, tom lane

In response to

Responses

pgsql-patches by date

Next:From: Peter BiermanDate: 2000-12-05 06:02:55
Subject: Re: darwin pgsql patches
Previous:From: Tom LaneDate: 2000-12-01 15:49:01
Subject: Re: darwin pgsql patches

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group