Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DirectoryConfig.workDir not working with Xcode 11 integration with SPM #207

Open
0xTim opened this issue Jun 8, 2019 · 6 comments
Open

DirectoryConfig.workDir not working with Xcode 11 integration with SPM #207

0xTim opened this issue Jun 8, 2019 · 6 comments
Labels
bug

Comments

@0xTim
Copy link
Member

@0xTim 0xTim commented Jun 8, 2019

In Xcode 11, if you open the Package.swift file directly (to get a new Xcode 11 Swift Package project) uses of DirectoryConfig.workDir fail, probably due to DerviedData being in a new place. This breaks .env and Leaf etc.

Current workaround - use swift package generate-xcodeproj and use the generated project

@0xTim

This comment has been minimized.

@tanner0101 tanner0101 added the bug label Jun 11, 2019
@tanner0101 tanner0101 added this to To Do in Vapor 3 via automation Jun 11, 2019
@tanner0101 tanner0101 added this to To Do in Vapor 4 via automation Jun 11, 2019
@tanner0101

This comment has been minimized.

Copy link
Member

@tanner0101 tanner0101 commented Jun 11, 2019

This is a tricky one to solve. It looks like Xcode 11 w/ SPM is using a #file path in the system DerivedData. This path has no correlation to where the source code is for the actual project, so the hacks we have in place currently for automatic detection no longer work.

I think the best solution here is to rely on setting a "Custom Working Directory" in the scheme.

Screen Shot 2019-06-11 at 4 06 33 PM

Since Xcode 11 SPM settings are now persisted in the .swiftpm folder, you only need to set this option once.

For Vapor 4, this can be the default behavior of DirectoryConfiguration.detect() since Xcode 11 will be required.

For Vapor 3, we will need some logic to skip the current #file hacks when Xcode 11 is being used, but continue to use the hacks with Xcode 10. The resulting file path in Xcode 11 contains SourcePackages/checkouts which I believe should be unique enough to successfully determine whether we are in Xcode 11 or 10.

I'll put up a PR now w/ this fix and we can test it out.

@tanner0101

This comment has been minimized.

Copy link
Member

@tanner0101 tanner0101 commented Jun 11, 2019

PR here: #208

@Yasumoto

This comment has been minimized.

Copy link

@Yasumoto Yasumoto commented Jun 11, 2019

I didn’t think of this immediately, so just leaving it for folks as a temporary workaround: in the meantime I’m just using swift run from terminal while using Xcode 11 for editing (and of course, SPM support!)

@tanner0101

This comment has been minimized.

Copy link
Member

@tanner0101 tanner0101 commented Jun 11, 2019

Another workaround is to register a custom DirectoryConfig only in Xcode:

#if Xcode
services.register { container in
    return DirectoryConfig(workDir: "/path/to/package")
}
#endif
@0xTim

This comment has been minimized.

Copy link
Member Author

@0xTim 0xTim commented Jun 12, 2019

(Workaround doesn't scale when working across teams/computers for those wondering)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Vapor 3
  
To Do
Vapor 4
  
To Do
3 participants
You can’t perform that action at this time.