Add executorFactory option to package manifest.

[al45tair]

This lets you specify which executor factory to use in the Package.swift.

rdar://148430450

[al45tair]

@swift-ci Please smoke test

[MaxDesiatov]

What's the corresponding Swift Evolution proposal/pitch for this? IIUC changes to PackageDescription public API are usually required to be pitched before merging.

[dschaefer2]

Yup, a quick pitch should be fine just to let the community know. Also some tests :).

[al45tair]

What's the corresponding Swift Evolution proposal/pitch for this?

Pitch is here:
https://forums.swift.org/t/pitch-2-custom-main-and-global-executors/78437

Also some tests :).

Indeed, I'd like to add some tests, though I find the SwiftPM repo hard to navigate so it would be useful if someone could point me in the right place(s) for that.

[MaxDesiatov]

You could modify the existing testBuildSettings in BuildPlantTests.swift, although it probably be better to create a separate test function so that it can run in parallel when these are migrated to Swift Testing.

[jakepetroules]

@al45tair Please add a new build setting in Swift Build for this as well. When using the Swift Build build engine backend we're not going to be using OTHER_SWIFT_FLAGS to pass down these sort of things.

[bkhouri]

chore (blocking): Would it be possible to add an automated tests that verify, at a minimum:

• A valid value is passed for the executor factory
• an invalid value is passed to the executor Factory
• the executor factory is not specified

This will ensure we the behaviour works as intended and that it does not regress

[al45tair]

Would it be possible to add an automated tests that verify, at a minimum:

• A valid value is passed for the executor factory
• an invalid value is passed to the executor Factory
• the executor factory is not specified

This will ensure we the behaviour works as intended and that it does not regress

It doesn't make sense to test all of that here. Tests of compiler options belong in the compiler tests. SwiftPM might reasonably test that the option is passed through to the compiler — it shouldn't be testing compiler behaviour.

[al45tair]

(I'll add to that that I think it would make a lot of sense if SwiftPM and Swift Build picked up options automatically from the .td files in the main Swift repo; there could be a flag that causes the option to be added to the swiftSettings automatically. For a lot of compiler options, including this one, that would be more than sufficient and would avoid people working on compiler features having to open two separate PRs and write separate sets of tests for each of these things. swift-driver already does pretty much this, though it isn't wholly automated and you need to open a PR against it to get an option added.)

[al45tair]

@swift-ci Please test