[swift-evolution] [Question] Absolute paths in executable .swiftmodule files

[Pepper Lebeck-Jobe]

Hello Swift-ers,

My name is Pepper Lebeck-Jobe, and I'm working on adding Swift support to
the Gradle Build Tool <https://gradle.org>. One feature that Gradle has
recently added is support for a Build Cache
<https://docs.gradle.org/current/userguide/build_cache.html>. 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:

   1. Between build invocations in a single workspace (think git working
   directory.)
   2. Between build invocations on the same machine run by the same user,
   even across multiple workspaces.
   3. Between build invocations across a whole development team (if a
   remote/centralized implementation of the build cache is deployed.)

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.

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:

   1. The XCC options. Namely, the argument to `-working-directory`
   2. The SEARCH_PATH used for finding modules.

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.

Questions:

   - Is there a way to tell swiftc to use relative paths instead of
   absolute?
      - If not, would a pull request adding such an option be welcomed?
   - 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?

Thanks,
Pepper Lebeck-Jobe

Further details:

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)

https://github.com/apple/swift/blob/6607ff73ce7a039fe76e45e5870f21ce6b524f60/lib/Frontend/CompilerInvocation.cpp#L1178-L1179


Abbreviated output from llvm-bcanalyzer -dump

<CONTROL_BLOCK NumWords=61 BlockCodeSize=3>
    <MODULE_NAME abbrevid=4/> blob data = 'Conductor'
    <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)'
    <TARGET abbrevid=6/> blob data = 'x86_64-unknown-linux'
    <OPTIONS_BLOCK NumWords=22 BlockCodeSize=3>
      <IS_SIB abbrevid=4 op0=0/>
      <IS_TESTABLE abbrevid=5/>
      <SDK_PATH abbrevid=6/> blob data = '/'
      <XCC abbrevid=7/> blob data = '-working-directory'
      <XCC abbrevid=7/> blob data = '/home/pepper/dev/gh/eljobe/Conductor'
    </OPTIONS_BLOCK>
  </CONTROL_BLOCK>
  <INPUT_BLOCK NumWords=45 BlockCodeSize=4>
    <SEARCH_PATH abbrevid=9 op0=0 op1=0/> blob data = '/home/pepper/dev/
github.com/eljobe/Conductor/.build/x86_64-unknown-linux/debug'
    <IMPORTED_MODULE abbrevid=4 op0=0 op1=0/> blob data = 'Orchestra'
    <IMPORTED_MODULE abbrevid=4 op0=0 op1=0/> blob data = 'Swift'
    <IMPORTED_MODULE abbrevid=4 op0=0 op1=0/> blob data =
'SwiftOnoneSupport'
    <IMPORTED_MODULE abbrevid=4 op0=0 op1=0/> blob data = 'Violin'
  </INPUT_BLOCK>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170914/ed0105a4/attachment.html>