Re: OS X 10.11.1, non-existing SDK after latest El Capitan update, x11/modular-xorg-xquartz

[Tobias Nygren <tnn%NetBSD.org@localhost>]

On Sun, 25 Oct 2015 11:16:26 -0400
Greg Troxel <gdt%ir.bbn.com@localhost> wrote:

> Tobias Nygren <tnn%NetBSD.org@localhost> writes:
> 
> > On Sun, 25 Oct 2015 12:58:01 +0100
> > Adam Ciarci?ski <adam%NetBSD.org@localhost> wrote:
> >
> >> I believe the lines cited above must be reduced to one MAKE_ENV, as OSX_SDK_PATH is defined in mk/platform/Darwin.mk:
> >> MAKE_ENV+=              OSX_SDK_PATH=${OSX_SDK_PATH}
> >> 
> >> Please, give it a try (I don't use X11 on OS X at all) and let me know it that works.
> >
> > This is how it was implemented previously.
> > The problem is that Darwin.mk does not always define OSX_SDK_PATH.
> > If /usr/include/stdio.h exists it will be left undefined.
> 
> This seems complicated and I realize there are good reasons, but I don't
> see why setting OSX_SDK_PATH should belong in individual makefiles,
> rather than having mk/* set things correctly.
> 
> Is the issues that xquartz someone only builds with an sdk, vs things in
> /usr/include?

Yes, it needs frameworks it can link against, from
${OSX_SDK_PATH}/System, not ${OSX_SDK_PATH}/usr/include. So, again,
it would be good if we could change Darwin.mk in a way that it always
makes an effort to set OSX_SDK_PATH. But I don't know about the
historical reasons for why it is done the way it is, currently.