[MacPorts] #71051: Macports should add a global "use_xcode yes" config option

[MacPorts]

#71051: Macports should add a global "use_xcode yes" config option
--------------------------+--------------------
  Reporter:  mouse07410   |      Owner:  (none)
      Type:  enhancement  |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+--------------------

Comment (by ryandesign):

 Replying to [comment:9 mouse07410]:
 > > a number of ports "bake in" the path to the SDK, and sometimes the
 paths to other things, into the installed build files.
 >
 > Is it truly necessary? It sounds to me like a sure path to troubles.

 Quite the contrary of being necessary, we believe it is an undesirable
 practice. Nevertheless, many projects do this, baking not only the SDK
 path but often all of the other CFLAGS, CXXFLAGS, CPPFLAGS, LDFLAGS, and
 compiler choices that were used to build that software into the files that
 they install so that these choices infect anything else built by that
 software. See #68095 for the most recent instance I came across (yorick)
 but there are many others (notably perl). It is difficult for us to fix
 this since often this is a deliberate design decision by the designers of
 the software. We have tried to fix it in perl but in general our job
 should just be to package upstream software, not to make changes to it. It
 may take a considerable effort for us to convince the developers that it
 is a bad design and then more effort for them to redesign their ecosystem
 to avoid it.

 >  > Over the years we have standardized on this path to the baked-in
 components being into the SDK installed with the CLTs.
 >
 > Yeah, I understand. But wouldn't using the output of {{{xcrun --show-
 sdk-path}}} be far better?

 Unless the output of `xcrun --show-sdk-path` is exactly
 `/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk` (replacing `12`
 with your major OS version), no, that would not be better. And since we
 already know the exact CLT SDK path we want, there's no need to run an
 external program to get it, especially since `xcrun` does not exist on
 every macOS version MacPorts works on.

 On my system, the output of `xcrun --show-sdk-path` is
 `/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk`,
 so no, that is not what we want baked into the badly-designed projects
 that bake in the SDK path, because then that software would require the
 full Xcode to be installed, which users have often balked at because it is
 so large. It also does not specify the SDK version, which means it would
 use the latest SDK version, and this is a frequent source of problems when
 compiling software not designed with an understanding of how macOS SDKs
 work. It is much more reliable to use the SDK version that matches the OS
 version. Xcode frequently only includes the latest SDK, whereas the CLT
 typically contains both the latest SDK and the one that matches the OS
 version, so this is another reason why we prefer using the CLT SDK for
 software that does not require Xcode.

 > Yes, except that CLT tend to be broken much more often than Xcode itself
 (and that's quite a high bar!),

 I'm not aware of this.

 > and some other toolchains (Haskell, for example) can't work with it.

 I'm not aware of this either.

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