So the 5861/5862 have been merged now, which means that we can build SourceKit on Linux with:
swift/utils/build-script -R -T --libdispatch -- --reconfigure swift/utils/build-script -R -T --libdispatch --extra-cmake-options="-DSWIFT_BUILD_SOURCEKIT:BOOL=TRUE" -- --reconfigure I'd like to get SourceKit building by default on Linux in a single pass, so that things like PR tests will compile and run the SourceKit code on Linux and make it easier for downstream to depend on the SourceKit library. I have updated 5903 which triggers an explicit 'make' call to build libdispatch. It's probably the wrong thing to do but it works. However the right approach would be to make the native libdispatch library (not the Swift part) an explicit component upon which the SourceKit could depend on Linux. Is the right approach to configure an external cmake dependency in this way, or is there a preferred alternative? If the solution in 5903 is the right way of doing it, what else needs to be passed out to the recursive make call? Alex > On 22 Nov 2016, at 18:05, Alex Blewitt via swift-dev <swift-dev@swift.org> > wrote: > > I have created a few pull requests regarding SourceKit support on Linux: > > https://github.com/apple/swift/pull/5861 > <https://github.com/apple/swift/pull/5861> - Update documentation for > building on Linux > https://github.com/apple/swift/pull/5862 > <https://github.com/apple/swift/pull/5862> - Allow SourceKit to be built > without errors on Linux > https://github.com/apple/swift/pull/5903 > <https://github.com/apple/swift/pull/5903> - Allow SourceKit to be built by > default on Linux (contains 5862) > > Because SourceKit isn't currently built on Linux as part of the build > process, it was missing dependencies on lto and coverage, both of which are > needed to build successfully. > > SourceKit depends on the native libdispatch implementation, which on Darwin > is satisfied by the current platform. On Linux, the approach has been to > build a two-pass of swift; first without the SourceKit support, and then with > the SourceKit support. The second time around, the SourceKit build can pick > up the libdispatch library from the previous build. > > The fix I've implemented in pull 5903 is to add a dummy dependency when > building SourceKit and on Linux that requires the libdispatch library exists, > and if it doesn't, to shell out to make it. It's ugly, but it works, and > SourceKit can be built in a single pass (though it still compiles libdispatch > twice). This would allow SourceKit to be used on Linux for other tools to > take advantage of. > > More strategic solutions might look like: > > * Refactoring the libdispatch build to use CMake - possibly unlikely, since > the libdispatch project has dependencies on libkqueue and libpwq, both of > which are external projects that use autoconf. > * Splitting out SourceKit to its own repository/project, and then > interleaving the dependencies such that SourceKit could depend on the > libdispatch project on Linux and not on Darwin. > * Changing the build script such that the libdispatch native library is built > first, prior to the main Swift project, but build the libdispatch Swift code > subsequently (potentially in a single repository, but may need two steps) > > Since these alternatives require more work, and may not be applicable at the > current time, I've taken the approach of creating the simplest thing that > works (albeit unashamedly ugly) for pull 5903. > > Comments welcome. > > Alex > _______________________________________________ > swift-dev mailing list > swift-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-dev
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
