swiftlang / swift-package-manager

The Package Manager for the Swift Programming Language
Apache License 2.0
9.73k stars 1.34k forks source link

Unused modulemap appears in build.db after rebuilding package #5565

Open philipturner opened 2 years ago

philipturner commented 2 years ago

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 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.

Steps to reproduce

  1. Open the reproducer Colab notebook.
  2. Run each cell, restarting the runtime before you continue to the next cell.

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

This was originally reproduced on the November 12, 2021 nightly development snapshot.

philipturner commented 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.

philipturner commented 2 years ago

@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".