gpsd @3.19: fails to build in trace mode

[Ionic (Mihai Moldovan)]

[...]
:info:build scons: done reading SConscript files.
:info:build scons: Building targets ...
:info:build rm -f ais_json.i && /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python jsongen.py --ais --target=parser > ais_json.i && chmod a-w ais_json.i
:info:build Creating 'gpsd_config.h'
:info:build /usr/bin/clang -arch x86_64 -o bits.os -c -Os -O2 bits.c
:info:build xcrun: error: invalid active developer path (/Applications/Xcode.app/Contents/Developer), missing xcrun at: /Applications/Xcode.app/Contents/Developer/usr/bin/xcrun
:info:build scons: *** [bits.os] Error 1
:info:build scons: building terminated because of errors.
:info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.rsync.ionic.de_release_ports_net_gpsd/gpsd/work/gpsd-3.19" && /opt/local/bin/scons -j2 prefix=/opt/local target_python=/opt/local/bin/python2.7 qt=yes usb=yes strip
=no dbus_export=no xgps=no 
:info:build Exit code: 2
:warn:build The following existing files were hidden from the build system by trace mode:
:msg:build   /Applications/Xcode.app/Contents/Developer/usr/bin/xcrun
:msg:build   /Applications/Xcode.app/Contents/Developer/usr/lib/libxcrun.dylib
[...]

Trace mode in base now only allows the Xcode paths by default if build.type is xcode. gpsd uses the "normal" gmake-based build type, but its configure phase still checks for and uses Xcode. Boom.

We now need to add

if {[info exists use_xcode]} {
    use_xcode "yes"
}

to make this work.

Can commit and push. Maintainers, are you okay with this change?

[fhgwright (Fred Wright)]

I guess this isn't quite as bad as it looks from the summary, since it only applies to the unreleased base. :-)

I'm not sure why you're referencing "configure phase", when this port doesn't have one. SCons combines configure and build.

I'm also not sure where the xcrun reference comes from, unless clang is invoking it. The build procedure doesn't reference it.

That being said, I don't have a problem with the change if it fixes the problem without breaking it for the released base (which I'm guessing the the purpose of the "info exists").

[Ionic (Mihai Moldovan)]

Replying to fhgwright:

I guess this isn't quite as bad as it looks from the summary, since it only applies to the unreleased base. :-)

Well, I did set the base version to 2.5.99, so yes, only trunk/master is currently affected.

I'm not sure why you're referencing "configure phase", when this port doesn't have one. SCons combines configure and build.

Yeah, it doesn't use a configure phase as such, but the build procedure still uses scons that does some configuring and Makefile generation. It's a mere technicality, though.

I'm also not sure where the xcrun reference comes from, unless clang is invoking it. The build procedure doesn't reference it.

Neither scons nor gpsd reference it. I guess it must be the system clang, which really only installs a shim into /usr/bin/clang that uses xcrun to get the "actual" developer dir and invoke the real binary - at least on 10.9. I don't know if newer macOS versions would even exhibit that problem because I think I've read that nothing is installed into /usr/ directly. That might get problematic for a lot of ports, actually, but I've only seen issues with gpsd so far.

That being said, I don't have a problem with the change if it fixes the problem without breaking it for the released base (which I'm guessing the the purpose of the "info exists").

Exactly. Thanks.

[Mihai Moldovan <ionic@…>]

In 74dc7dca8679cac57c49c4f87cc3208982735d68/macports-ports (master):

net/gpsd: mark as using Xcode - unbreaks trace mode builds.

While technically the port doesn't use any Xcode utility, it looks like
the shims in /usr/bin do that implicitly to call the actual clang
binary.

Fixes: #58770

[neverpanic (Clemens Lang)]

This change should no longer be necessary since [e09517b2ebf0ca18cd7b6e66ac3ffafba48296b3/macports-base], because DEVELOPER_DIR is now exported which should cause the shims to prefer the command line tools. Can you please re-try with the change in base?

[neverpanic (Clemens Lang)]

OK, so I've tried without your change it is still fails, which suggests that DEVELOPER_DIR is not being set in the environment. This may be a SCons-specific issue…

[neverpanic (Clemens Lang)]

Yeah, SCons cleans the environment when running commands. You need to import the DEVELOPER_DIR from the environment for this to work correctly on a machine with both Xcode and CLTs and trace mode enabled.