So the reason Jeremy set these tool wrappers up to be invoked by xcrun is that
xcrun adds a number of useful default settings ("sugar") and envvars to the
toolchain.
This does things like spec the appropriate sdkroot, etc… a reasonable summary
is here:
https://keith.github.io/xcode-man-pages/xcrun.1.html
You will see people saying their builds can't find the SDK, for example, and
trying to set that in their bootup shell scripts -- but that's often because
they aren't using Apple's tools the right way. Jeremy, being a compiler
engineer for Apple, certainly knew the right way.
There are nearly 40,000 buildable ports on Macports, and they have all been
tested to build with the current setups. Changing core things like this can
have untold and widespread effects.
It sounds like you are trying to build some things with an old version of the
developer tools on 10.7 and running into troubles. Perhaps the xcrun in those
older versions doesn't work the way the last set of developer tools works on
10.7.
This generates a question - should MacPorts be modified, possibly in an
unfavourable way, to allow folks to do things like this? My vote has always
been no -- MacPorts can really only be expected to support one consistent set
of toolchain tools for each system. In general, that means the last xcode that
Apple provided for each system.
(There are a couple of exceptions, where the latest xcode provided an SDK that
was one OS version newer than the system version. In those systems, to have a
matching SDK to the system, Ryan has held back the xcode version to the last
that matched the system. This is really not ideal, and the better option is to
use the newest supported xcode with an added SDK that matches the system - but
that has not as yet been automated and so we are stuck with this discrepancy
for now.)
So I'd say that if you have an unusual use case, where you want to run an old
xcode version on a specific system for your own reasons -- that is not
something that MacPorts should be modified to start supporting.
Ken
Sent from my iPhone
> On Dec 25, 2024, at 9:47 AM, Gagan Sidhu via macports-dev
> <[email protected]> wrote:
>
> i think it’s an old and unneeded workaround for newer clangs. could someone
> look into this?
>
> i know that it’s not needed for newer clangs and, if anything, will frustrate
> any potential users from staying with our package manager.
>
> in my experience i’ve found this macro to be more of a hindrance than a
> positive. i would appreciate a resolution to improve our competitiveness in
> this space.
>
> Thanks,
> Gagan
>
>> On Dec 25, 2024, at 10:45 AM, Ryan Carsten Schmidt <[email protected]>
>> wrote:
>>
>> On Dec 25, 2024, at 11:40, Gagan Sidhu wrote:
>>>
>>> it’s the scripts or macro check for xcrun are causing a problem:
>>>>
>>>> vms-Mac-2:MacOS vm$ cat /opt/local/bin/clang++-mp-17
>>>> #!/bin/bash
>>>>
>>>> if [ -x /usr/bin/xcrun ] ; then
>>>> exec /usr/bin/xcrun /opt/local/libexec/llvm-17/bin/clang++ "${@}"
>>>> else
>>>> exec /opt/local/libexec/llvm-17/bin/clang++ "${@}"
>>>> fi
>>
>> Oh. I didn't know our clang was a wrapper script that did this.
>>
>>
>
