Jeremy Schonfeld

@etcwilde @al45tair any chance you have any insight on what's going on here? For reference, in the standard Linux toolchain we have: ``` /usr/lib/swift_static/linux/_FoundationCollections.swiftmodule /usr/lib/swift_static/linux/lib_FoundationCollections.a /usr/lib/swift/linux/_FoundationCollections.swiftmodule ``` (in the non-static...

> @jmschonfeld, is the `_SwiftCollections_SourceDIR` flag required for these files to be installed? Foundation needs _some_ copy of swift-collections to build, but the parameters determine where that source copy comes...

> perhaps the variable has to be set for CMake to then finally install that static library and modules No, the variable strictly defines the location of the source checkout...

@al45tair should we move this issue over to the swift-collections repo if we need to make the CMake fix there? cc @lorentey since this likely entails tagging a new swift-collections...

> -- SwiftSyntax_DIR not provided, checking out local copy of swift-syntax Looks like we need to make sure `SwiftSyntax_DIR` gets passed along to the separate macro build

Actually I got my wires crossed - in the toolchain build, swift-foundation should already receive `SwiftFoundation_MACROS` from the build script so it shouldn't ever hit the `ExternalProject` path, right?

If they are logically equivalent to extended attributes then to me it'd make sense to provide them in the same manner that we provide extended attributes on Unix platforms. However...

@jrflat I believe this is the new behavior of `URL`, so you might be able to look into this. @gregcotten I'd be interested hearing more about how this breaks your...

Thanks for catching this, I wonder if there's an alternative API that we can be using here that would allow us to determine if the file is executable even if...

@swift-ci please test