Rebranch swift-package-manager for swift-3.0. #592
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… leave the boilerplate framework Info.plist files out of the project hierarchy
- This is primarily so the logic for merging the sets can be factored onto it.
SR-2262 Generated Xcode projects should leave the boilerplate framework Info.plist files out of the project hierarchy
This is the beginnings of a bottom-up constraint solver, but backtracking is
unimplemented.
I plan to document the motivations for taking this resolution strategy in more
detail, but for now the jist is below.
The assumption based on the problem domain is that the most logical notion to
the user is that of resolving the dependencies for an individual package in
isolation, simply because each dependency is presumably developed by someone,
and that is the situation that that developer is in.
Given that assumption, it is useful to frame the dependency resolver in terms of
solving individual packages with some amount of additional constraints imposed
(those additional constraints represent the impact of other dependencies in the
graph on that individual package). I believe this will allow us to give good
diagnostics of the form:
Dependency A: 1.0.0 ..< 2.0.0 could not be resolved with the following additional constraints:
B_0: ...
...
B_N: ...
and then we can provide tools so that the author of `A` can trial the resolution
of their package with those additional constraints active. This is designed to
allow the *author* of the dependency which is causing dependency resolution
issues to be in a good position to resolve the dependency problem (without
needing to necessarily examine the client package, which may not be accessible
to them).
It remains to be seen how efficiently we can implement this strategy, but my
motivation is to build an algorithm which gives good diagnostics first, and
focus on performance second.
…by any means but is an opportunistic improvement made as part of a larger diff).
- This can happen when the manager state has become inconsistent with the file system state.
…erated Xcode project based on whether `llvm-profdata` exists next to the swiftc that's being used (that is also the swiftc that's set as the SWIFT_EXEC in the generated scheme so this should always match).
…milar to the lines of output for the other stages of bootstrap.
- This is just so it is clear what types we want to use for synchronization at the layers above Basic...
At least one of the tests is timing out. This reverts commit 42309df.
- This is just so it is clear what types we want to use for synchronization at the layers above Basic... - This fixes a problem with me and Mr. De Morgan in the previous commit which could cause the tests to not wait appropriately before the broadcast.
- This also normalizes exactly what version information can be overridden by the bootstrap script.
…ile. - This should become private eventually, we want to define loading in terms of a complete package not just the manifest (in case in the future we expose other parts of the package to the manifest loading process).
- This feature is only partially implemented, and isn't actually used by anything. Unfortunately, it also conflicts with some of the work I need to do on SE-0135 in a way that is non-trivial to fix right now. I'm ripping it out for now, we can land it again once this feature has been fully designed and implemented.
- Instead of recomputing out of thin are the expected tag for a version, use the map established in the previous commit.
Renaming Streamable => TextOutputStreamable [Do not merge]
- This fixes a serious regression where `versions` was expected to be in order... it also boosts our test coverage of this scenario in two ways and adds an assertion on the internal invariant which wasn't previously documented.
- This is one part of SE-0135.
- This is the second part of SE-0135.
- This also adds an end-to-end function test of the behavior.
- Also, improve functional test coverage of `swift package init`.
|
/cc @rballard @tkremenek |
|
@swift-ci please test |
|
OS X tests passed but failed due to config problem, I think. Linux tests failed in XCTest, I don't know what is going on with that but it doesn't appear related to these changes. I am going to go ahead and merge this and work through any fallout. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This effectively rebranches swift-3.0 for the Swift Package Manager to master, primarily in order to take the changes for SE-0135 and other bug fixes that have landed. We are still in the position of needing to regularly do substantial refactoring when we land changes, so cherry-picking individual fixes is not yet feasible.