Re: [PATCHES] add darwin/osxpb support to cvs

>Next time you can make your patch with "diff -crN" so that you don't have
>to create a separate tarball.

No problem. I tried just doing a diff with cvs but wasn't able to get
the -N option to work. This is the first time I've ever tried
patching unix software so I'm sorry if it's a bit messy. Thanks for
you help in getting it right.

> > - the config.guess and config.sub files have been updated by apple to
>> support their new os. i don't think these changes have been folded
>> back in to the main archive yet
>
>I installed the latest ones from GNU which claim to support it according
>to the ChangeLog.

I'll try checking out the new versions and see if they work. I can
send you a diff with the ones I have here if you want to see the
additions Apple made.

> > I've followed the BeOS example of including the necessary sem.h
>> declarations in src/include/port/darwin.h. this is rather messy at the
>> moment and can be dumped once apple releases a version of PB with sysv
>> sem built into the kernel.
>
>The include/port/beos.h isn't really a shining example of how to do this. 
>This file is include *everywhere*, but we don't want to know about
>semaphores everywhere. I'd prefer it if you use the QNX approach and
>symlink sem.h into an include directory (e.g., /usr/local/include/sys),
>since it's only temporary anyway.

I agree it's rather messy. I originally had just used the sym link in
/usr/local/include, but as I said, some of the newer Darwin kernels
have the sysv sem.h file already there and I was worried about people
overwriting it. If you think it's fair to put this responsibility on
the end user, I'm ok with that. I just thought it might be nice to
check and see if the semaphore implementation was already there, and
if not, build the necessary parts. I'll switch it back to the way it
was.

>I'm also somewhat concerned about the dynloader.c because it's under the
>Apache license which has a funny advertisement clause. Comments from
>someone?

I wondering about this too. I'll try emailing Wilfredo Sanchez and
see if I can get the code outside the Apache license. This would
probably be easiest.

>The compiler probably predefines something like __darwin__, which you
>should use. You can find out with

It doesn't actually provide __darwin__ but as I mentioned in a
previous post, Apple is suggesting people use __APPLE__ combined with
__ppc__ or __i386__ for the different darwin builds. The section in
s_lock.c should probably be changed to reflect this instead of using
DARWIN_OS.

>And finally, what's up with this:
>
>CFLAGS='-O0 -g -traditional-cpp'
>
>? What's wrong with the "modern-cpp"?

Apple's "modern-cpp" called cpp-precomp uses some strange parsing
that breaks on several files in the postgresql build. They are still
working on it apparently and are suggesting people simply use the
-traditional-cpp flag when this happens instead of trying to update
the files.

Thanks again for all your comments and suggestions.

Bruce