Skip to content

Use the correct module name for executable targets combined with an executable product with a different name #9480

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
owenv merged 1 commit into from
Dec 11, 2025
+61 −2
Merged

Use the correct module name for executable targets combined with an executable product with a different name #9480

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 20 additions & 0 deletions Fixtures/Miscellaneous/TestableExeWithDifferentProductName/Package.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
// swift-tools-version: 5.5
import PackageDescription

let package = Package(
name: "TestableExe",
products: [
.executable(name: "testable-exe", targets: ["TestableExe"])
],
targets: [
.executableTarget(
name: "TestableExe"
),
.testTarget(
name: "TestableExeTests",
dependencies: [
"TestableExe",
]
),
]
)
5 changes: 5 additions & 0 deletions Fixtures/Miscellaneous/TestableExeWithDifferentProductName/Sources/TestableExe/main.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
public func functionFromTestableExecutable() {
print("Hello, world")
}

functionFromTestableExecutable()
8 changes: 8 additions & 0 deletions ...laneous/TestableExeWithDifferentProductName/Tests/TestableExeTests/TestableExeTests.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
import XCTest
@testable import TestableExe

final class TestableExeTests: XCTestCase {
func testExample() throws {
functionFromTestableExecutable()
}
}
5 changes: 3 additions & 2 deletions Sources/SwiftBuildSupport/PackagePIFProjectBuilder+Products.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -112,7 +112,8 @@ extension PackagePIFProjectBuilder {
settings[.TARGET_NAME] = product.name
settings[.PACKAGE_RESOURCE_TARGET_KIND] = "regular"
settings[.PRODUCT_NAME] = "$(TARGET_NAME)"
settings[.PRODUCT_MODULE_NAME] = product.c99name
// We must use the main module name here instead of the product name, because they're not guranteed to be the same, and the users may have authored e.g. tests which rely on an executable's module name.
settings[.PRODUCT_MODULE_NAME] = mainModule.c99name
Copy link
Contributor

@bkhouri bkhouri Dec 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: can we add a PIFBuilder Test that will validate we don't regress this behaviour?

Copy link
Contributor Author

@owenv owenv Dec 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's really important in this case that we ensure packages compile instead of just producing valid PIF, which is why I added the full text fixture above. Otherwise we might generate valid PIF which then fails to compile the user's sources.

settings[.PRODUCT_BUNDLE_IDENTIFIER] = "\(self.package.identity).\(product.name)"
.spm_mangledToBundleIdentifier()
settings[.SWIFT_PACKAGE_NAME] = mainModule.packageName
Expand Down Expand Up @@ -415,7 +416,7 @@ extension PackagePIFProjectBuilder {
case .executable, .snippet:
// For executable targets, we depend on the *product* instead
// (i.e., we infuse the product's main module target into the one for the product itself).
let productDependency = modulesGraph.allProducts.only { $0.name == moduleDependency.name }
let productDependency = modulesGraph.allProducts.only { $0.mainModule?.name == moduleDependency.name }
if let productDependency {
let productDependencyGUID = productDependency.pifTargetGUID
self.project[keyPath: mainModuleTargetKeyPath].common.addDependency(
Expand Down
25 changes: 25 additions & 0 deletions Tests/CommandsTests/TestCommandTests.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -317,6 +317,31 @@ struct TestCommandTests {
}
}

@Test(
.IssueWindowsLongPath,
.tags(
.Feature.TargetType.Executable,
),
arguments: SupportedBuildSystemOnAllPlatforms, BuildConfiguration.allCases,
)
func testableExecutableWithDifferentlyNamedExecutableProduct(
buildSystem: BuildSystemProvider.Kind,
configuration: BuildConfiguration,
) async throws {
try await withKnownIssue(isIntermittent: true) {
Copy link
Contributor

@bkhouri bkhouri Dec 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue (blocking): can we add a .bug() trait referencing the GitHub issue that track the Windows intermittent failure?

Copy link
Contributor Author

@owenv owenv Dec 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is what IssueWindowsLongPath is for, no? It's marked intermittent so the ongoing work to resolve those issues doesn't trigger "known issue was not recorded" failures

try await fixture(name: "Miscellaneous/TestableExeWithDifferentProductName") { fixturePath in
let result = try await execute(
["--vv"],
packagePath: fixturePath,
configuration: configuration,
buildSystem: buildSystem,
)
}
} when: {
.windows == ProcessInfo.hostOperatingSystem
}
}

@Test(
.tags(
.Feature.TargetType.Executable,
Expand Down
Loading