Closed felix91gr closed 7 years ago
Here is the output of the ./swift/utils/update-checkout --help
command:
usage: update-checkout [-h] [--clone] [--clone-with-ssh] [--skip-history]
[--skip-repository DIRECTORY] [--scheme BRANCH-SCHEME]
[--reset-to-remote] [--clean] [--config CONFIG]
[--github-comment GITHUB-COMMENT] [--dump-hashes]
[--tag TAG-NAME] [-j N_PROCESSES]
repositories.
By default, updates your checkouts of Swift, SourceKit, LLDB, and SwiftPM.
optional arguments:
-h, --help show this help message and exit
--clone Obtain Sources for Swift and Related Projects
--clone-with-ssh Obtain Sources for Swift and Related Projects via SSH
--skip-history Skip histories when obtaining sources
--skip-repository DIRECTORY
Skip the specified repository
--scheme BRANCH-SCHEME
Use branches from the specified branch-scheme. A
"branch-scheme" is a list of (repo, branch) pairs.
--reset-to-remote Reset each branch to the remote state.
--clean Clean unrelated files from each repository.
--config CONFIG Configuration file to use
--github-comment GITHUB-COMMENT
Check out related pull requests referenced in the
given free-form GitHub-style comment.
--dump-hashes Dump the git hashes of all repositories being tracked
--tag TAG-NAME Check out each repository to the specified tag.
-j N_PROCESSES, --jobs N_PROCESSES
Number of threads to run at once
The --scheme
and the --tag
options are the ones that could be used for this.
The swift-3.1-DEVELOPMENT-SNAPSHOT-2017-03-02-a
tag is the last one that passed the tests in Jenkins.
I called the update-checkout
like this, and it finished without errors. So far, so good:
./swift/utils/update-checkout --clone --tag swift-3.1-DEVELOPMENT-SNAPSHOT-2017-03-02-a
I'm going to compile it and run the tests now, to see if it really downloaded passing/good commits for every repo.
By default, the build-script
doesn't compile the SourceKit binaries. Therefore, if it works with the default presets, I'm gonna try it using Jin's. He used them to have Source Kite working natively.
sourcekitdInProc
library, but it is not linked correctly. It should be linked to libdispatch.so
, which I did compile. I'll try some tests. I might've compiled SourceKit wrongly: instead of letting the system know where libdispatch.so
was beforehand, I compiled it right away and left it without the library.Closed in lieu of #2
Why is this a good idea
Because Source Kite running in Docker, while functional, is not as efficient as we could get it.
It would be ideal to have it running natively in the OS.
Steps to do this
1) Get the complete Swift 3.1 binaries
Currently, the snapshots provided at swift.org don't include the SourceKit project. SourceKit is the base of Source Kite, which is the backend of SDE. Therefore, if we can get SourceKit to install and work, we can theoretically build everything from there.
Since the complete binaries aren't yet provided by swift.org, we should compile them instead.
2) Check that SourceKit works, and build Source Kite from it
Current ideas being tried to make this work
Compiling the sources of the latest CI successes
The commits of the Swift Projects are tested in Jenkins in order to provide Continuous Integration. The SHAs of the last commit of every repository that were used in a successful run, are written in the testing results.
What we would do with them is:
update-checkout
script, and thenupdate-checkout
and check if the toolchain builds and worksIf it does, then we can probably build Source Kite on top of it.