Hubert Feyrer <hubert%feyrer.de@localhost> writes:
>> How is building against a newer SDK than what you are running going to
>> work? I confess I haven't tried this in a bulk build yet, but I'm
>> pretty sure it's going to end badly (or worse, in ways that are hard
>> to debug).
>>
>> For now the only sensible route seems to be installing the Command
>> Line Tools as indicated, until Apple either start shipping the 10.10
>> SDK in XCode 7, or stop tricking 10.10 users into upgrading to an
>> XCode which doesn't support their system.
>
> If you have 10.9 and update Xcode, that's the situation that you end
> up: A working build environment, where only pkgsrc doesn't work. I
Is it really working? Or are you building for 10.10 on 10.9, and many
programs work, but the situation is unsound? I had a similar experience
earlier, where many programs worked and some failed to run becuase of a
missing symbol. That and others having similar issues others led to
pkgsrc making sure it was using the SDK appropriate for the running
system, rather than the default SDK (which was inexplicably not the
running system).
> don't think that denying users (and me) a working pkgsrc "just
> because" is a useful option, as there is a patch available that fixes
> the situation.
I don't see it that way; it's a question of what are the requirements
pkgsrc imposes on the platform, and what are our standards for
soundness, because people building things with the wrong SDK will lead
to random bug reports that don't make sense. I can believe that 10.10
to 10.11 changes are not that big a deal and that building cross for
10.11 produces binaries that usually work on 10.10.
> Index: mk/platform/Darwin.mk
> ===================================================================
> RCS file: /cvsroot/pkgsrc/mk/platform/Darwin.mk,v
> retrieving revision 1.76
> diff -u -r1.76 Darwin.mk
> --- mk/platform/Darwin.mk 14 Dec 2015 14:14:33 -0000 1.76
> +++ mk/platform/Darwin.mk 5 Jan 2016 13:03:56 -0000
> @@ -95,6 +95,10 @@
> OSX_VERS:= ${OSX_VERS:R}
> . endif
> OSX_SDK_PATH!= /usr/bin/xcrun --sdk macosx${OSX_VERS} --show-sdk-path 2>/dev/null || echo /nonexistent
> +. if !empty(OSX_SDK_PATH:M/nonexistent)
> +OSX_VERS!= /usr/bin/xcodebuild -showsdks | grep '.*-sdk macosx' | sed 's,.*macosx,,'
> +OSX_SDK_PATH!= /usr/bin/xcrun --sdk macosx${OSX_VERS} --show-sdk-path 2>/dev/null || echo /nonexistent
> +. endif
> . if exists(${OSX_SDK_PATH}/usr/include/stdio.h)
> _OPSYS_INCLUDE_DIRS?= ${OSX_SDK_PATH}/usr/include
> MAKEFLAGS+= OSX_VERS=${OSX_VERS:Q}
I am not comfortable with this being default behavior, because it
silently patches over a real issue -- that the system does not contain
an SDK for the currently-running system version.
Also, this needs a comment explaining it, and assigning OSX_VERS with a
value that is perhaps multiple lines seems iffy.
If we know that 10.11 binaries always work on 10.10, then perhaps we
could allow that special case. (I find Apple's behavior boggling in
this case - not providing an SDK target for the current version does not
make sense, but maybe there is a secret rule that developers are not
allowed to not upgrade.)
The bigger question is how much complexity to admit. pkgsrc has to
declare prerequisites and then rely on them, and as that set gets more
complicated, there are more issues. I think the view that a system that
can't build native binaries is broken is reasonable, especially when
"install command line tools" is an easy solution.
> Index: devel/p5-Curses/Makefile
> ===================================================================
> RCS file: /cvsroot/pkgsrc/devel/p5-Curses/Makefile,v
> retrieving revision 1.52
> diff -u -r1.52 Makefile
> --- devel/p5-Curses/Makefile 18 Aug 2015 07:31:05 -0000 1.52
> +++ devel/p5-Curses/Makefile 5 Jan 2016 12:56:16 -0000
> @@ -19,7 +19,7 @@
> SUBST_STAGE.h_form = post-configure
> SUBST_MESSAGE.h_form = Hard wiring form.h
> SUBST_FILES.h_form = c-config.h
> -SUBST_SED.h_form = -e 's,<form.h>,"/usr/include/form.h",g'
> +SUBST_SED.h_form = -e 's,<form.h>,"${OSX_SDK_PATH}/usr/include/form.h",g'
>
> MAKE_PARAMS+= FORMS MENUS
It seems odd to have an OSX variable in OS-independent code, but I see
the point. Definitely needs a comment explaining why this is safe on
other than OSX.
I wonder if it would be better to fix the compilation to respect the
include path; it seems odd that this is necessary at all. But I have
no idea how hard that is, and the presence of the transform is a clue
that it is hard.
Attachment:
signature.asc
Description: PGP signature