<div dir="ltr">On Wed, Jun 1, 2016 at 2:18 PM, Daniel Dunbar via swift-dev <span dir="ltr"><<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi all,<br>
<br>
The current build process for the overall Swift project (i.e., the compiler + associated projects like Foundation, XCTest, and SwiftPM) relies on each project having dependencies on the built artifacts of previously built projects. Those dependencies are currently communicated to each project in the chain through an ad hoc set of arguments to the individual project's build process. This has been painful to maintain, and makes it hard to reason about the environment that each of the associated projects are building within.<br>
<br>
Instead, I would like to move towards what I have been calling a "toolchain-based" build process.<br>
<br>
In this model:<br>
<br>
1. The entire build process will be organized as a sequential, incremental construction of a complete toolchain.<br>
- Each individual project will build and copy its products into a staging area.<br>
2. The build script will always create a composed toolchain.<br>
- It will start with an empty toolchain, and merge in the content from each project as it builds.<br>
- This will use rsync & hard-links to avoid needing to stay fast.<br>
3. Each individual project build will just use the composed toolchain to build.<br>
- This will replace the grab bag of options we use to communicate between the projects.<br>
4. At the end of the build, we will have constructed a complete toolchain which can be installed (or used with Xcode).<br>
<br>
Aside from simplifying the overall build process, this has a couple very nice upsides:<br>
<br>
1. At the end of the build, the user has a complete toolchain. They can install it, or use it as they would a distributed snapshot. This is very beneficial for people who are only building the Swift project to get a more recent version of the compiler.<br>
<br>
2. Each individual project can be built using the "official" build process with a downloaded snapshot (assuming it is of a new enough version). This is very beneficial for easing contribution to projects like Foundation, XCTest, and SwiftPM which are pure Swift and have fast build times, but which currently build in Swift CI using a very different process from the snapshot-based workflow.<br>
<br>
Concrete details:<br>
<br>
1. I do not plan to change the actual install process in the short term. The actual install process used today relies on the CMake-based install process for some projects (most importantly Swift) and isn't suitable for use in this fashion (where incremental development speed is of high importance). Instead, my plan is to teach the build script itself how to assemble the staging area for each individual project, with the long term goal of using that for the official install process instead of the CMake-based process.<br>
<br>
2. My plan is that the build script would only support building one "primary product" (i.e. toolchain). That product may itself be a complete cross compiler toolchain with support for multiple platforms, but the expectation is that users would invoke the build script multiple times if building multiple toolchains. However, to support Canadian Cross [1] build scenarios the build script may need to manage the construction of two products, the primary toolchain and the intermediate (cross compiling) toolchain used to build the artifacts in the primary toolchain.<br>
<br>
3. As a concrete example of a problem this solves, SwiftPM currently doesn't test its `swift-test` product in Swift CI, because that product requires using all of the toolchain stack (swift, Foundation, and XCTest), but the product itself is only intended to be used as part of a concrete toolchain. As such, it doesn't know how to operate correctly when given the piecemeal build products for each of those projects, and teaching it to do so would be very cumbersome for us to maintain.<br>
<br>
Feedback welcome!<br></blockquote><div><br></div><div>Overall, I think that this would be a great change.</div><div><br></div><div>I am however slightly confused on why the build script needs to be concerned about candian cross at all if it can be taught how to use a specified toolchain.</div><div><br></div><div>Because these (standard at least as per auto tools) terms can be confusing:</div><div><br></div><div>[1] build - the platform where things are being built</div><div>[2] host - the platform where the generated binaries will be run</div><div>[3] target - the platform where the binaries generated by the compiler on the host platform will run</div><div><br></div><div>It should be possible to shift the burden on the user. They would be responsible for the first stage of the canadian cross (to build a toolchain capable of generating binaries for the host platform). Then invoke the build script a second time with the toolchain they just built to cross-compile the cross-compiling toolchain.<br></div><div><br></div><div>Or did I completely misunderstand your detail point 2 and this is the expectation?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- Daniel<br>
<br>
[1] <a href="https://en.wikipedia.org/wiki/Cross_compiler#Canadian_Cross" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Cross_compiler#Canadian_Cross</a><br>
<br>
_______________________________________________<br>
swift-dev mailing list<br>
<a href="mailto:swift-dev@swift.org">swift-dev@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-dev</a></blockquote></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div>
</div></div>