<div dir="ltr">Tony,<div><br></div><div>Thanks for redirecting this conversation to the swift-dev mailing list. I wasn't 100% sure I was pointing in the right direction. I'm moving swift-evolution to the BCC (that way we won't keep bothering them.)</div><div><br></div><div>Thanks,</div><div>Pepper<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 14, 2017 at 6:13 PM Tony Allevato <<a href="mailto:tony.allevato@gmail.com">tony.allevato@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks for bringing this up, Pepper!<div><br></div><div>We have many of the same issues with our Swift support in <a href="https://github.com/bazelbuild/bazel" target="_blank">Bazel</a>; since .swiftmodule files aren't hermetic, we can't reliably cache them. The proliferation of import paths in the modules is another major issue—as part of our recent work to start building Bazel support for <a href="https://github.com/apple/swift-protobuf" target="_blank">Swift protocol buffers</a>, we end up generating a potentially large tree of modules and having the transitive closure of a module's dependencies' import paths in the .swiftmodule files causes those files to grow significantly.</div><div><br></div><div>I've pointed another one of our engineers to this thread where he can provide better details.</div><div><br></div><div>(I'm adding swift-dev@ onto this thread because I think it might be more appropriate there and you might be more likely to get better answers; it's not really a language evolution topic AFAICT.)</div><div><br></div><br><div class="gmail_quote"></div></div><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Sep 14, 2017 at 1:48 AM Pepper Lebeck-Jobe via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello Swift-ers,<div><br></div><div>My name is Pepper Lebeck-Jobe, and I'm working on adding Swift support to the <a href="https://gradle.org" target="_blank">Gradle Build Tool</a>. One feature that Gradle has recently added is support for a <a href="https://docs.gradle.org/current/userguide/build_cache.html" target="_blank">Build Cache</a>. This feature enables fine-grained work avoidance by snapshotting/fingerprinting/hashing all of the inputs of a particular task (unit of work) and writing the output of the task to a cache. This cache can be shared:</div><div><ol><li>Between build invocations in a single workspace (think git working directory.)<br></li><li>Between build invocations on the same machine run by the same user, even across multiple workspaces.</li><li>Between build invocations across a whole development team (if a remote/centralized implementation of the build cache is deployed.)</li></ol><div>However, for the sharing of task outputs to be useful, it must be possible to reuse the outputs in any build which is running with the same exact inputs.</div><div><br></div><div>This is where we are running into a little bit of trouble with our current implementation of Swift support. We have noticed that when we build Swift executables, the .swiftmodule file corresponding to the executable contains some strings which are absolute paths. Using llvm-dcanalyzer -dump we were able to see that these absolute paths are of two general types:</div><div><div><ol><li>The XCC options. Namely, the argument to `-working-directory`</li><li>The SEARCH_PATH used for finding modules.</li></ol><div>My limited understanding of these absolute paths in the .siwftmodule files of executables is that they are used when debugging the executable. The problem is, if we cache the .swiftmodule file and try to use it when compiling the exact same executable on a different machine or even in a different workspace on the same machine, we may break the end-user's ability to debug the resulting executable. Note: We haven't actually tried this yet and seen it broken. Let us know if our concerns are unfounded.</div></div></div></div><div><br></div><div>Questions:</div><div><ul><li>Is there a way to tell swiftc to use relative paths instead of absolute?</li><ul><li>If not, would a pull request adding such an option be welcomed?</li></ul><li>If we reuse the output (complete with incorrect absolute paths) what would be failure mode? That is, which development-time or runtime use cases would not work?</li></ul><div>Thanks,</div><div>Pepper Lebeck-Jobe</div><div><br></div><div>Further details:</div></div><div><br></div><div>Code which leads me to believe I should be able to use an empty -working-directory argument in combination with a relative -I <relative-search-path> argument to get the paths to be relative (although, it doesn't work)</div><div><br></div><div><a href="https://github.com/apple/swift/blob/6607ff73ce7a039fe76e45e5870f21ce6b524f60/lib/Frontend/CompilerInvocation.cpp#L1178-L1179" target="_blank">https://github.com/apple/swift/blob/6607ff73ce7a039fe76e45e5870f21ce6b524f60/lib/Frontend/CompilerInvocation.cpp#L1178-L1179</a> <br></div><div><br></div><div>Abbreviated output from llvm-bcanalyzer -dump</div><div><br></div><div><div><CONTROL_BLOCK NumWords=61 BlockCodeSize=3></div><div> <MODULE_NAME abbrevid=4/> blob data = 'Conductor'</div><div> <METADATA abbrevid=5 op0=0 op1=363 op2=3 op3=3/> blob data = '4.1(4.1)/Swift version 4.1-dev (LLVM f06eb26858, Clang 65adc04c91, Swift 8c65f6e785)'</div><div> <TARGET abbrevid=6/> blob data = 'x86_64-unknown-linux'</div><div> <OPTIONS_BLOCK NumWords=22 BlockCodeSize=3></div><div> <IS_SIB abbrevid=4 op0=0/></div><div> <IS_TESTABLE abbrevid=5/></div><div> <SDK_PATH abbrevid=6/> blob data = '/'</div><div> <XCC abbrevid=7/> blob data = '-working-directory'</div><div> <XCC abbrevid=7/> blob data = '/home/pepper/dev/gh/eljobe/Conductor'</div><div> </OPTIONS_BLOCK></div><div> </CONTROL_BLOCK></div><div> <INPUT_BLOCK NumWords=45 BlockCodeSize=4></div><div> <SEARCH_PATH abbrevid=9 op0=0 op1=0/> blob data = '/home/pepper/dev/<a href="http://github.com/eljobe/Conductor/.build/x86_64-unknown-linux/debug" target="_blank">github.com/eljobe/Conductor/.build/x86_64-unknown-linux/debug</a>'</div><div> <IMPORTED_MODULE abbrevid=4 op0=0 op1=0/> blob data = 'Orchestra'</div><div> <IMPORTED_MODULE abbrevid=4 op0=0 op1=0/> blob data = 'Swift'</div><div> <IMPORTED_MODULE abbrevid=4 op0=0 op1=0/> blob data = 'SwiftOnoneSupport'</div><div> <IMPORTED_MODULE abbrevid=4 op0=0 op1=0/> blob data = 'Violin'</div><div> </INPUT_BLOCK></div></div></div></blockquote></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div></blockquote></div></div></div>