[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 satraul):

 Replying to [comment:8 Ionic]:
 >   2. Override the Developer dir path via the DEVELOPER_DIR environment
 variable if we don't want to use Xcode (i.e., if `use_xcode` is `no`).
 Example:

 This is what we're implementing now with the new variable
 `configure.developer_dir` which is set to CLT when Xcode isn't requested.
 So we're now actually exporting DEVELOPER_DIR to an extent:
 [31e0c5619836ebfc23c812b2d9f65d3c98938efa/macports-base]

 But it turns out that wasn't enough because things like `build { system -W
 /usr/bin/clang }` was ignoring this change, so it was solved with this:
 [e09517b2ebf0ca18cd7b6e66ac3ffafba48296b3/macports-base]

 So with that change, I expected that it would solve this problem too: when
 `qmake` runs `xcrun` to find SDK, it should have DEVELOPER_DIR set thus
 finding CLT's SDK. I'm not sure why this isn't the case.

 ----

 > > I just found out that there are many ports (~150) that depend on
 qmake, so I think we should consider a larger solution. Ccing my project
 mentors.
 >
 > Well, ports that use qmake(5) usually also use the qmake(5)-1.0
 PortGroups, so it would be easy to just change the two as a workaround.
 There are some ports that don't use the PGs, but they probably should do
 so anyway.
 >
 > This said, we probably don't want to use yet another workaround anyway.
 Such a workaround would essentially use option one and be put into every
 port (or PortGroup) that uses the system clang compiler, which we also do
 by default most of the time. Not really a good option.

 Right, it's nice to know that we still have that workaround just in case.

 Thank you for the explanations, I've understood a bit more (or less) about
 what's happening.

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