@swift-ci create

CC @belkadan/@ddunbar/@aciidb0mb3r

Xcode has no trouble building swift-nio even in the presence of the bogus string.h so I'd say this is a SwiftPM issue, tagging it as such for now even through it might be a bogus default in clang/swiftc.

I think we looked into this before and it turns out to come from how the command-line tools work on macOS without being invoked through xcrun, or maybe without an explicit SDK (either from xcrun or from -sdk). Ankit, do you have the discussion for that?

(As in, this is expected behavior on macOS and we aren't going to change it.)

@belkadan wait, xcrun swift build would workaround this?

This is xcrun's behavior when an explicit SDK is not passed and `swift build` goes through xcrun on macOS. From xcrun's man page:

       CPATH
          This  environment variable is modified by xcrun to include /usr/local/include when an explicit SDK is not requested via environment vari-
          able nor command line argument and neither -nostdinc nor -nostdsysteminc are present.

@weissi It'll work if you run `xcrun -sdk macosx swift build`

This has known to cause one other similar issue so far. I don't know if it's a good idea for SwiftPM to try to detect and unset this env variable.

@aciidb0mb3r oh nice, thank you! Hmm, I think SwiftPM and Xcode should behave the same by default?

I agree that they should but this is an unfortunate bug because of the implementation details of the underlying tools. There's no way to properly detect if CPATH was set by xcrun or not.

yup...