add deprecation warning to 'generate-xcodeproj'

[tomerd]

motivation: Starting Xcode 11, packages are directly supported by Xcode and the generate-xcodeproj command is no longer needed

changes:

• add deprecation warning that generate-xcodeproj will be deprecated soon
• add test

rdar://problem/65633238

[tomerd]

@swift-ci please smoke test

[unnamedd]

Hi @tomerd,

I don't want to come here to create any kind of disturb around of this decision, but if you don't mind, would you explain a bit better why this decision was taken? What was the rationale?

Even if the Xcode support packages directly, one of the great benefits of the Swift Package Manager is exactly the generation of the Xcode project. I'm sure that a lot of people in the community uses this resource. Talking about myself, my way to work is almost always the same:

-> swift package init
-> configure some dependencies on Package.swift
-> swift package generate-xcodeproj

Accept my apologies if I'm missing some previous decision, I'm not being so active in the Swift community in the last few months and maybe I'm not up to date.

Personally speaking, I don't think the deprecation of the generate-xcodeproj a nice decision for us all, maybe I'm possibly being selfish here, but after the deprecation, our way to generate Xcode projects based on the SPM projects, will be a bit more bureaucratic.

[MaxDesiatov]

Talking about myself, my way to work is almost always the same:

-> swift package init
-> configure some dependencies on Package.swift
-> swift package generate-xcodeproj

I'm genuinely curious, is there any benefit to following these steps instead of just opening Package.swift in Xcode? Seems like the latter is easier and doesn't require any additional actions.

[unnamedd]

Talking about myself, my way to work is almost always the same:
-> swift package init
-> configure some dependencies on Package.swift
-> swift package generate-xcodeproj

I'm genuinely curious, is there any benefit to following these steps instead of just opening Package.swift in Xcode? Seems like the latter is easier and doesn't require any additional actions.

To be really honest, I'm in shock @MaxDesiatov because this is something I never tried. I used to copy the folder directly to some existing project, but never tried to open the folder itself without a xcodeproj.

Indeed, after your pointing I guess I was overworking here! 😱

Thanks a lot @MaxDesiatov!

[tomerd]

@swift-ci please smoke test

[Cyberbeni]

Talking about myself, my way to work is almost always the same:
-> swift package init
-> configure some dependencies on Package.swift
-> swift package generate-xcodeproj

I'm genuinely curious, is there any benefit to following these steps instead of just opening Package.swift in Xcode? Seems like the latter is easier and doesn't require any additional actions.

I haven't used Carthage in a while but it looks to me that Package.swift support is still not done yet: Carthage/Carthage#2867

[MaxDesiatov]

There are two options then:

1. Carthage generates an Xcode project for a given Package.swift on its own. This implementation would also be predictable, as Carthage can then fully control the generation process as it sees convenient. Carthage can then expect that this behavior won't break in future versions of SwiftPM and wouldn't need to rely on this behavior it can't control.
2. Users that currently rely on Carthage migrate to SwiftPM, which is a cross-platform package manager that in addition to Apple platforms and Linux now also supports Windows and WebAssembly. This also reduces the maintenance burden from such users, as to support those platforms they only need a single package manager. And if SwiftPM lacks any functionality present in Carthage that they need, it should be reported so that SwiftPM is improved to accommodate more users.

[Cyberbeni]

The main advantage of Carthage is that it prebuilds rarely changing dependencies for you (and creates a lock file, so that the same version is used across development environments), speeding up the build process. (Especially if clean build means that the prebuilt dependencies are kept if their version and Xcode version didn't change)

I don't really use SPM currently either (We have our own internal system for dependency management), but I think this is not supported yet and have been already requested before.

[MaxDesiatov]

The main advantage of Carthage is that it prebuilds rarely changing dependencies for you

This was available in SwiftPM since its first version, as far as I'm aware. Running swift build prebuilds dependencies for you, and repeated runs of swift build or swift test don't rebuild dependencies that were already prebuilt.

and creates a lock file, so that the same version is used across development environments

Is there anything missing in Package.resolved generated by SwiftPM solving the same problem?

[Cyberbeni]

At all the places I worked at, release builds required to be clean builds and built dependencies could be kept but had to be rebuilt from 0 when their version (or the used Xcode version) changed. If you want that with SPM, you have to write additional code for your release flow instead of just using swift builld

[MaxDesiatov]

Since Swift 5.3 you can use binary dependencies and XCFramework format to achieve the same result. What additional code is needed then?

[Cyberbeni]

Let's say you want to add Realm as a dependency which is not distributed in a binary format (through Package.swift) but you want to keep its build product while its (and Xcode's) version is unchanged and clean build it when updating versions. Meanwhile you want to both clean build and incremental build your local code (on different machines).

Totally different topic: XCFramework requires “Build Libraries for Distribution”, does that result in the exact same performance if it was built with the same compiler version? As far as I understand, it sacrifices some amount of performance but allows you to update the framework and app separately (for example when distributing a kernel extension and a framework that other apps can dlopen during run). Or is the only reason to not make that the default is to avoid it's side effect of requiring @unknown default case for non-frozen enums?

[AndreiVidrasco]

I'm genuinely curious, is there any benefit to following these steps instead of just opening Package.swift in Xcode? Seems like the latter is easier and doesn't require any additional actions.

I believe there is.

Generating xcodeproj gives you control over downloading dependencies(well, at least if feels like it)

When you open a Package.swift file, it immediately starts to download all packages(anyone testing this on low speed internet connection btw?)

When I open a XcodeProj file it does nothing(which is good). If I really want to download packages, I have a command to run and I control the process.

To give examples:
I often find myself, downloading something from github and I just want to open the project, to look over the files.
It's a library, I don't have anything to run there(well, maybe tests, but usually there is a badge on github page saying they're all green), so I don't really care if dependencies are loaded.
So, I just want to navigate through the directory .
I open the Package.swift file and it downloads all the dependencies(which is not possible to disable).
And when I tried to close it, I see an alert, if I want to stop some action. Action which I never started.

Comparing to opening a generated (and committed in git) xcodproj.
Dependencies are all missing in the respective folder. But nothing starts to download. I can navigate through all files in the package. I can close it. If I want to download the dependencies, I just recreate xcodeproj.

[jabwd]

I don't know if this is a good change. I have an entire army of swift PM projects that specifically require an xcode-project because xcode for some reason refuses to understand that /usr/local exists. There are workarounds of course but none are clean as far as I can tell but I'd love to be proven wrong on that part

[tomerd]

I have an entire army of swift PM projects that specifically require an xcode-project because xcode for some reason refuses to understand that /usr/local exists.

could you elaborate please so we can address these cc @neonichu @abertelrud

[jabwd]

It is usually a problem when I try to use things like Ed25519 implementation using libsodium or IO through libevent, which are most easily installed using homebrew. The go-to way for me to make this a buildable project is either through CLI or by adding /usr/local/lib to the linker flags and /usr/local/include to the header search paths in a generated xcode project for development. I must admit I haven't tested this with Xcode 12.2 but it was still a problem when I was using 12.0 on catalina. I can provide project samples as they aren't bound to any specific license -- but i'm probably taking over the PR at this point so I'd be willing to provide these somewhere more suitable.

[tomerd]

Started https://forums.swift.org/t/rfc-deprecating-generate-xcodeproj/42159 to track this follow-on discussion

[kenji21]

At all the places I worked at, release builds required to be clean builds and built dependencies could be kept but had to be rebuilt from 0 when their version (or the used Xcode version) changed. If you want that with SPM, you have to write additional code for your release flow instead of just using swift builld

We also do this, all CI builds are clean ones, (I tried to add a cache to Carthage), and now that we are moving to SPM, I was thinking of speeding up our CI pipeline by a tool that builds xcframework (or check if already in cache) for each dependency found in Package.resolved and then replace them with a "local one"
Of course such a tool will be built in swift:

swift run cache-packages-toolname Path/to/Package.resolved ~/Library/Cache/SPMBuildCache

before running any xcodebuild commands

[tmaly1980]

fastlane scan depends in there being an xcodeproj file in order to run unit tests in an automated CI environment. I realize there's the "swift test" program, but I'm developing for iOS only and it has no way of specifying the platform to build for. It expects me to support macOS and I am not wanting to.

[MaxDesiatov]

You can use xcodebuild for packages that don't have an Xcode project, as described here https://stackoverflow.com/a/62246008/442427