[MacPorts] #58779: base: ports cannot use SDK inside of Developer dir unless using Xcode build type

[MacPorts]

#58779: base: ports cannot use SDK inside of Developer dir unless using Xcode build
type
---------------------+-----------------------
  Reporter:  Ionic   |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  base    |    Version:  2.5.99
Resolution:          |   Keywords:  tracemode
      Port:          |
---------------------+-----------------------

Comment (by Ionic):

 > So it seems we can't find a clear solution to always use CLT for qt5
 then.

 If it only used the tools suite, that would have been possible. However,
 since Qt5 (and likely also Qt4) heavily use SDKs, it's impossible to find
 a generic way, since SDKs are only installed by Xcode on older platforms.
 I don't have a 10.10 machine that I could look into, but 10.9 only ships
 SDKs as part of Xcode, while 10.11 has an SDK embedded in the CLT. I
 suspect that CLTs started shipping SDKs with Xcode 7 (denoting 10.10), but
 I'm not sure. There is another slight problem in that the SDK shipped by
 CLT on the 10.11 box is one for 10.12, but that's a known problem (and
 SHOULD, theoretically, not cause problems if the deployment target is set
 correctly).
 \\\\
 > If I get it right: even if qmake could use CLT's SDK on <=10.9 there is
 difficulty in doing so, such as xcrun not behaving correctly as you
 pointed out. I initially thought that the solution was by hacking how to
 call qmake so it could resolve correctly to macosx, but that is now ruled
 out.

 That's (part of) the problem: CLT doesn't ship an SDK on 10.9-. qmake
 expects one, though, and won't be happy if it can't resolve the SDK value
 it's looking for. I tried disabling its SDK usage, but that only led to
 some other error. The reason for that is that qmake tries to look for the
 `xcodebuild` binary, c.f.,
 `${prefix}/libexec/qt5/mkspecs/features/mac/default_pre.prf`. With
 DEVELOPER_DIR set to the CLT directory, that call fails. I **could** work
 around that failure by setting `$QMAKE_XCODE_DEVELOPER_PATH` (qmake/env
 variable) directly/explicitly to `${configure.developer_dir}` in order to
 skip the `xcodebuild` check, but that would only lead to the build failing
 later AGAIN, because it would go on to auto-detect the Xcode version via
 `/usr/bin/xcodebuild -version`. That call fails if DEVELOPER_DIR is set to
 the CLT developer dir.

 I wonder how that worked for neverpanic? Well,
 [https://github.com/qt/qtbase/blob/5.12/mkspecs/features/mac/default_pre.prf
 here's the explanation]: they refactored the code to NOT check for
 `xcodebuild` when looking for the developer dir, split it out and made it
 non-fatal **and** they stopped checking for the Xcode version if the
 `xcodebuild` path is empty. This stands in stark contrast to
 [https://github.com/qt/qtbase/blob/5.8/mkspecs/features/mac/default_pre.prf
 code in older versions] of qt5base.
 \\\\
 > I'll wait for my mentors to chime in, but I guess the acceptable fix is
 to set use_xcode for qt5 temporarily for now, right?

 It would be a workaround. The better fix would be to backport the changes
 that make Xcode usage optional to older Qt5 versions (since, like
 previously said, Qt5 has a habit of deprecating macOS versions quite
 aggressively, so that older platforms are forced to use older,
 unmaintained Qt5 versions). I don't know how much effort that would be,
 though. There were definitely changes to that one file, which are crucial,
 but we might need even more changes to make it work **correctly** (see
 opportunistic compiler usage, which [UsingTheRightCompiler is not what we
 want].
 \\\\
 > Also: is there an easy way of testing across macOS versions? Would be
 nice to know

 Not aware of any way. I have two VMs as build hosts for some other
 project, currently running 10.11 and 10.13, and my old MBP, running 10.9.
 Theoretically, it also includes a 10.6 VM, but that is hopelessly outdated
 by now. Haven't started it in a year or even longer.

 CLTs should be freely downloadable through the developer portal, though.
 Even if one doesn't intend to install them, I think that getting the file
 list is still possible by executing the installer and using the "Show
 Package contents" option. It's not a comfortable way and actually
 extracting this stuff would be more difficult. The same applies more or
 less to Xcode. Note that such packages are HUGE.

-- 
Ticket URL: <https://trac.macports.org/ticket/58779#comment:18>
MacPorts <https://www.macports.org/>
Ports system for macOS