<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 3, 2016, at 1:14 PM, Saleem Abdulrasool <<a href="mailto:compnerd@compnerd.org" class="">compnerd@compnerd.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">On Wed, Jun 1, 2016 at 2:18 PM, Daniel Dunbar via swift-dev<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:swift-dev@swift.org" target="_blank" class="">swift-dev@swift.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><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 class=""><br class="">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 class=""><br class="">Instead, I would like to move towards what I have been calling a "toolchain-based" build process.<br class=""><br class="">In this model:<br class=""><br class="">1. The entire build process will be organized as a sequential, incremental construction of a complete toolchain.<br class=""> <span class="Apple-converted-space"> </span>- Each individual project will build and copy its products into a staging area.<br class="">2. The build script will always create a composed toolchain.<br class=""> <span class="Apple-converted-space"> </span>- It will start with an empty toolchain, and merge in the content from each project as it builds.<br class=""> <span class="Apple-converted-space"> </span>- This will use rsync & hard-links to avoid needing to stay fast.<br class="">3. Each individual project build will just use the composed toolchain to build.<br class=""> <span class="Apple-converted-space"> </span>- This will replace the grab bag of options we use to communicate between the projects.<br class="">4. At the end of the build, we will have constructed a complete toolchain which can be installed (or used with Xcode).<br class=""><br class="">Aside from simplifying the overall build process, this has a couple very nice upsides:<br class=""><br class="">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 class=""><br class="">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 class=""><br class="">Concrete details:<br class=""><br class="">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 class=""><br class="">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 class=""><br class="">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 class=""><br class="">Feedback welcome!<br class=""></blockquote><div class=""><br class=""></div><div class="">Overall, I think that this would be a great change.</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Because these (standard at least as per auto tools) terms can be confusing:</div><div class=""><br class=""></div><div class="">[1] build - the platform where things are being built</div><div class="">[2] host - the platform where the generated binaries will be run</div><div class="">[3] target - the platform where the binaries generated by the compiler on the host platform will run</div><div class=""><br class=""></div><div class="">It should be possible to shift the burden on the user.</div></div></div></div></div></blockquote><div><br class=""></div><div><div>Why would we _want_ to shift the burden to the user?</div></div><div><br class=""></div><div>From the user's perspective, they want to end up with a toolchain that compiles `Host -> Target`... I see it as an implementation detail (of the `build-script`) that producing what the user wants requires us to build the intermediate `Build -> Target` toolchain.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> 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 class=""></div></div></div></div></div></blockquote><div><br class=""></div>The tricky part of the canadian cross situation isn't the toolchain capable of generating binaries for the host, it is the toolchain capable of generating binaries for the target, but which needs to run on the build host. This is needed when you need to produce runtime libraries that will execute on the Target, but you are simultaneously trying to construct a cross compiler for a Host which you cannot actually execute. This is when you need the extra `Build -> Target` toolchain, and is the situation I was referring to.</div><div><br class=""></div><div> - Daniel</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">Or did I completely misunderstand your detail point 2 and this is the expectation?</div></div></div></div></div></blockquote><div><br class=""></div></div><div><br class=""></div><div> - Daniel</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></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 class=""><br class="">[1]<span class="Apple-converted-space"> </span><a href="https://en.wikipedia.org/wiki/Cross_compiler#Canadian_Cross" rel="noreferrer" target="_blank" class="">https://en.wikipedia.org/wiki/Cross_compiler#Canadian_Cross</a><br class=""><br class="">_______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-dev" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-dev</a></blockquote></div><div class=""><br class=""></div>--<span class="Apple-converted-space"> </span><br class=""><div class="gmail_signature" data-smartmail="gmail_signature">Saleem Abdulrasool<br class="">compnerd (at) compnerd (dot) org</div></div></div></div></blockquote></div><br class=""></body></html>