<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">We can’t separate building for ‘Build’ and building for an arbitrary ‘Host’. For those who don’t know, this is how cross-compiling works with Swift (this isn’t off-topic, I’m going to bring it back firmly to this proposal):</div><div class=""><br class=""></div><div class="">Currently, when you install the compiler, the standard library is in (prefix)/lib/swift/(Target)/(arch). On OSX, we cross-compile the standard library for the iOS targets, so you’ll see subfolders for ‘macosx’, ‘iphoneos’, etc in there. All you need to cross-compile in Swift is the standard library; swiftmodules don’t need ‘ar’, so libraries don’t even need any binutils to cross-compile, which is refreshing. A cross-linker *is* unfortunately still required for executables (come on, LLD!).</div><div class=""><br class=""></div><div class="">Grab the standard library from a linux machine and try:</div><div class="">echo 'print("hello, world")' | ./swiftc —target=x86-unknown-linux-gnu -resource-dir {PATH_TO_LINUX_STDLIB} -emit-module -<br class=""></div><div class=""><br class=""></div><div class="">So when we’re cross-compiling the swift portions of the standard-library, we’re using the swift compiler we just made for Build, telling it to use Host’s lib/swift directory, and there it will find the correct subdirectory for Target. My native compiler for my OSX Build machine knows not to look for the Linux host’s own Target in swift-macosx-x86_64/lib/swift, but in swift-linux-armv7/lib/swift.</div></div><div class=""><br class=""></div><div class="">—</div><div class=""><br class=""></div><div class="">Okay, so that’s out of the way.</div><div class=""><br class=""></div><div class="">There is an actual problem with how we build/configure the target libraries (Foundation, XCTest and libdispatch). We currently configure them like every other product (for each host), instead of for each target. A consequence of this is, for example, that we won’t try to build Foundation for cross-compile targets such as Android. What we should do is this:</div><div class=""><br class=""></div><div class="">For each host:</div><div class="">-> Build cmark/llvm/swift</div><div class="">-> For each target of this host:</div><div class="">-> -> Build Foundation/XCTest/libdispatch</div><div class="">-> Build swiftpm</div><div class=""><br class=""></div><div class="">When you look at it like this, from a tools // target-libraries perspective (swiftpm is an exception; it’s a host tool, but it depends on Foundation), I came up with a different idea (possibly, I’m not sure), that might also help the dependency issue, although I don’t know the specifics of it: I would suggest that after building swift, we install it, then build the target libraries and install them as we do so.</div><div class=""><br class=""></div><div class="">That would give us a stable standard-library (lib/swift) location which we could treat like an installed system. So when Foundation builds (for each Target now), it sets -resource-dir to the installed Host copy of swift, and the Build swift compiler can find Target’s standard library (yeah, I know). It installs itself in there. Then XCTest comes along, it sets the same -resource-dir, so now it can find Foundation just with ‘import Foundation’ and nothing else. In other words: every product after the swift compiler can assume its dependencies are like they’ve been installed on the system.</div><div class=""><br class=""></div><div class="">I’m not sure if that’s what you’re referring to with a ‘toolchain-based’ build process or not. The reason I think it might be is because I don’t think this would require big changes. We’d just have to install products after swift, then install the target libraries as we go. Foundation could even keep on generating build.ninja in-tree, sadly.</div><div class=""><br class=""></div><div class=""><div class="">There isn’t much difference between supporting one cross-host or supporting n cross-hosts. I would prefer ’n’, if we could get a nice argument syntax for it, because it’s more convenient to integrate with other tools, but it’s not a big deal. Actually, I have an idea for a better build-script argument syntax which would scale to NxM cross-compiled hosts and targets elegantly, but that’s a topic for another day.</div></div><div class=""><br class=""></div><div class="">Karl</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 3 Jun 2016, at 22:31, Daniel Dunbar via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><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 class=""><br class=""></div><div class=""><div class="">Why would we _want_ to shift the burden to the user?</div></div><div class=""><br class=""></div><div class="">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 class=""><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 class=""><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 class=""><br class=""></div><div class=""> - Daniel</div><div class=""><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 class=""><br class=""></div></div><div class=""><br class=""></div><div class=""> - Daniel</div><div class=""><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=""></div>_______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-dev<br class=""></div></blockquote></div><br class=""></div></body></html>