Re: darwin pgsql patches - Mailing list pgsql-patches

> >> > Why not use "__APPLE__"? There probably isn't much hope of running
> >> > anything on a Mac with MacOS which isn't also darwin, right?
> >> What about Rhapsody?
> Mac OS X exists in two forks at the moment. One of them is Mac OS X server, which is based on mach 2.5, and is a
snapshotof the Mac OS X development process from 1999. There are enough customers of this product that Apple has
continuedto bring that fork forward onto the latest machines, so that they can smoothly migrate them back onto the top
oftree when it ships as a server product. These people are either WebObjects developers who are probably deploying on
Solarisor HPUX, or Schools and Workgroups who need a high end AppleShareIP server. 
> Mac OS X top of tree is Mac OS X client, currently available as Mac OS X Public Beta. (Darwin, which is the name for
allof the Open Source parts, everything below the window server, is actually slightly more current.) When it's stable
enough,the server solution software will be sold on top of this codebase. 
> While there are probably several Mac OS X Server customers that would be interested in PG, I think you can safely
concentrateon Mac OS X (client, Public  Beta, darwin) with the knowledge that they will eventually come to you. 
> >fwiw (in case I'm coming across as *just* in a bad mood ;), it seems
> >like the right time to help Apple understand that they should be
> >building their compiler with predefined symbols so that the machine and
> >OS type can be identified automatically. In general, one expects that
> >from the compiler, though I'm sure we have exceptions in our supported
> >platforms.
> The list I sent is actually the list that was decided on about a year ago, after trimming a much longer list of stuff
thatthe compiler used to export. For that reason, I don't think you'll see it grow. 
> 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
thatOS. Is there some cost of #define __darwin__ in src/template/darwin that I'm not seeing? (not trying to be
inflamatoryhere. :-) 

No, no particular cost, other than in trying to distill the *actual*
properties of our code base down to the fundamental necessities.

In this case, ./configure can test for general properties of the system
as well as simply testing for the signiture used to set up things like
the ports/ files. If there is a testable property, we can write a test
for configure to try. If there is a signiture based on the results of
uname etc then configure can help select files for inclusion. But the
inline code which is #ifdef'd for specific platforms may as well stand
on its own if possible. So, for example, on Linux systems the "#ifdef
__linux__" was provided by the compiler, not by ./configure, though if
we had to we could try to come up with tests for determining that or we
could hardcode the definition into a ports/ file.

In your summary of MacOS-X, you indicated that we could assume a single
supported flavor, since the two existing code forks will eventually
merge. If there are not *other* Mac platforms which define "__APPLE__"
and which could also run PostgreSQL, then that symbol would likely be
the best choice for our inline tests. All imho of course. Peter E. has
been doing extensive work on the configure system recently, and may have
some more or different suggestions.

Regards.

                       - Thomas