Any thought to how to deal with packages with executables?

[thomasvl]

SwiftProtobuf seems to be failing for 5.3 for watchOS and iOS because our package also has executables and thus the watchOS, tvOS, and iOS builds fail. Since SwiftPM doesn't have a way to indicate this, any thoughts for how to avoid this and only build the valid subset?

https://swiftpackageindex.com/builds/28D5E7F0-04B9-413B-B04E-59DDF1154C03

[finestructure]

I've just had a quick look and the reason iOS, tvOS, and watchOS are failing is that we're not picking the correct scheme. I can build all three by adjusting that.

I can fix this up with an override but we're also trialling a config file that you could ship with the repo, if you'd like to give that a go: Add .spi.yml at the root of the package with the following content:

version: 1
builder:
  configs:
  - platform: ios
    scheme: SwiftProtobuf_iOS
  - platform: tvos
    scheme: SwiftProtobuf_tvOS
  - platform: watchos
    scheme: SwiftProtobuf_watchOS

[thomasvl]

So it will use a checked in Xcode project also? It wasn't clear if there was a way to get it to do that vs. using the Package.swift and newer Xcode support.

Should we just land this file and check in a few days to see if things do any better?

[finestructure]

Yes, we also use checked in project/workspace files. There's a little more detail here but essentially, we check xcodebuild -list but give up if there are multiple schemes and ignore project files altogether.

If you'd like to give that file a spin that'd be great. It'll only affect the default branch until release obviously. If you'd like the correct status reflected sooner I can also bring in the override (which I can set to affect all revisions) - let me know what you prefer. (The override will be ignored if you ship your own file later.)

[finestructure]

Also, please be aware that we may need to tweak this file quite a bit potentially. Hence the version number :)

[thomasvl]

If you'd like to give that file a spin that'd be great. It'll only affect the default branch until release obviously. If you'd like the correct status reflected sooner I can also bring in the override (which I can set to affect all revisions) - let me know what you prefer. (The override will be ignored if you ship your own file later.)

We're likely gonna have a release in the near future, so I'm good waiting for that to reflect it in the future.

Also, please be aware that we may need to tweak this file quite a bit potentially. Hence the version number :)

Yup, no worries, glad to see it thought of. 👍

Hopefully not overloading this issue too much the 5.0 and 4.2 builds generally seemed to fail with lots of issues. Is the spi.yml likely to help those, or will it need some more tweaking to get things right? We've got linux CI via github actions covering those versions, so they should be green. And last time I did manually checks in Xcode versions I thought things were working.

[finestructure]

I've just tested 5.0 and they should all turn green with that file - except you'll also need to pick the macOS scheme, i.e. add

  - platform: macos-xcodebuild
    scheme: SwiftProtobuf_macOS
  - platform: macos-xcodebuild-arm
    scheme: SwiftProtobuf_macOS

(The ARM one you could also skip since it's only available for 5.3 and that passes without a chosen scheme.)

Swift 4.2 seems to be failing for other reasons:

Selected platform:         ios
Swift version:             v4_2
Building package at path:  ./checkout
User defaults from command line:
    IDEClonedSourcePackagesDirPathOverride = /Users/sas/Downloads/checkout/.dependencies

resolved source packages:
Running build ...
env DEVELOPER_DIR="/Applications/Xcode_10.1.app" xcrun xcodebuild -IDEClonedSourcePackagesDirPathOverride="$PWD/.dependencies" -derivedDataPath "$PWD/.derivedData" build -scheme "SwiftProtobuf_iOS" -destination "generic/platform=ios"
User defaults from command line:
    IDEClonedSourcePackagesDirPathOverride = /Users/sas/Downloads/checkout/.dependencies
    IDEDerivedDataPathOverride = /Users/sas/Downloads/checkout/.derivedData

note: Using new build system
note: Planning build
note: Constructing build description
Build system information
error: SWIFT_VERSION '5.0' is unsupported, supported versions are: 3.0, 4.0, 4.2. (in target 'SwiftProtobuf_iOS')

Build system information
error: SWIFT_VERSION '5.0' is unsupported, supported versions are: 3.0, 4.0, 4.2. (in target 'SwiftProtobuf_iOS')

** BUILD FAILED **

Looks like that might be a genuine failure?

[finestructure]

PS: I ran all these against 1.11.0

[thomasvl]

error: SWIFT_VERSION '5.0' is unsupported, supported versions are: 3.0, 4.0, 4.2. (in target 'SwiftProtobuf_iOS')

Yea, so this is the problem with having to have a checked in Xcode project, we have to set the language version to something, right now it is set to 5 because that's the best choice for all our supported toolchains except the 4.2 one. And forcing all the newer Xcode's to use the older Swift Language Version also isn't right.

This is where it would be nice to build via SwiftPM and have it just ignore the executables since those are only buildable for Linux/macOS in general, but SwiftPM doesn't really express that. Is there a way to tell it to use the SwiftProtobuf instead of the SwiftProtobuf-Package scheme from the Package.swift? (although the 4.2 toolchains didn't have direct Xcode+SwiftPM support, so I guess you'd need to generate a project first also?)

[finestructure]

Mmm... the recommendation we got from the Apple SPM team was not to use SPM to build anything other than for macOS 😅 - if that was what you're suggesting.

One thing I tried just now was to remove the xcodeproj and regenerate it with 4.2's package generate-xcodeproj - and then build with xcodebuild. But that fails in a similar way to how iOS fails in later Swift versions when built with a -Package scheme:

 sas@Ceres  ~/D/checkout  ⎇ *…  env DEVELOPER_DIR="/Applications/Xcode_10.1.app" xcrun swift package generate-xcodeproj
generated: ./SwiftProtobuf.xcodeproj
 sas@Ceres  ~/D/checkout  ⎇ *…  env DEVELOPER_DIR="/Applications/Xcode_10.1.app" xcrun xcodebuild -IDEClonedSourcePackagesDirPathOverride="$PWD/.dependencies" -derivedDataPath "$PWD/.derivedData" build -scheme "SwiftProtobuf-Package" -destination "generic/platform=ios"
User defaults from command line:
    IDEClonedSourcePackagesDirPathOverride = /Users/sas/Downloads/checkout/.dependencies
    IDEDerivedDataPathOverride = /Users/sas/Downloads/checkout/.derivedData

note: Using new build system
note: Planning build
note: Constructing build description
Build system information
error: unable to resolve product type 'com.apple.product-type.tool' for platform 'iphoneos' (in target 'protoc-gen-swift')

Build system information
error: unable to resolve product type 'com.apple.product-type.tool' for platform 'iphoneos' (in target 'Conformance')

Build system information
error: unable to resolve product type 'com.apple.product-type.tool' for platform 'iphoneos' (in target 'protoc-gen-swift')

Build system information
error: unable to resolve product type 'com.apple.product-type.tool' for platform 'iphoneos' (in target 'Conformance')

Build system information
warning: duplicate output file '/Users/sas/Downloads/checkout/.derivedData/Build/Products/Debug-iphoneos' on task: Ld /Users/sas/Downloads/checkout/.derivedData/Build/Products/Debug-iphoneos normal arm64 (in target 'Conformance')

Build system information
warning: duplicate output file '' on task: Ld /Users/sas/Downloads/checkout/.derivedData/Build/Products/Debug-iphoneos normal arm64 (in target 'Conformance')

** BUILD FAILED **

Do you have a sequence of commands that'll get a passing build with 4.2/ios? I can try and map that to our build system to see if we could make that configurable.