You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 a Utilities 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 in Sources and the unused modulemap in Utilities.
In the reproducer notebook, it first builds the Swift package nested inside an encapsulating package (jupyterInstalledPackages1, located in /opt/swift/packages/1). It rebuilds jupyterInstalledPackages1 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.
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 philipturner/swift-colab#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
The text was updated successfully, but these errors were encountered: