Open philipturner opened 2 years ago
The reproducer Colab notebook was previously inaccessible because Google Drive did not authorize public access. I fixed the sharing settings, so you can now view the notebook.
@abertelrud would you mind taking a look at this? I'm trying to make Swift-Colab's build system more resilient and fix every bug reported in https://github.com/philipturner/swift-colab/issues/14. I can devote time to implementing the bug fix; I just don't know where to start. The Swift-Colab thread addresses this bug as "Problem 3".
Description
When building S4TF in Swift-Colab, there is a SwiftPM bug that causes a faulty CTensorFlow modulemap to overwrite the correct CTensorFlow modulemap. The "faulty" modulemap is not part of
Sources
or included by the package manifest. Rather, it's in aUtilities
directory originally used for making S4TF toolchains.In Colab, the package build system creates a strangely shaped package like discussed in #5482. That package has one source file and no
Sources
directory, recursively depending on S4TF. I made a special branch of S4TF for showcasing this bug: philipturner/fan/resurrection5. It is stripped down to one Swift file inSources
and the unused modulemap inUtilities
.In the reproducer notebook, it first builds the Swift package nested inside an encapsulating package (
jupyterInstalledPackages1
, located in/opt/swift/packages/1
). It rebuildsjupyterInstalledPackages1
in a subsequent command without changing the SwiftPM flags. It enters Python mode in order to use SQLite without spending time compiling PythonKit.Expected behavior
When querying build.db, there should never be modulemap files.
Actual behavior
When querying build.db after the first build, there are no modulemap files. After the second build, there is one modulemap file.
Steps to reproduce
Swift Package Manager version/commit hash
5.6.1
Swift & OS version (output of
swift --version && uname -a
)Swift 5.6.1
Ubuntu 18.04, x86_64