Skip to content
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.

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

No target named 'swift-openapi-generator-arm64-apple-macosx15.0-debug-tool.exe' in build description when doing --experimental-prepare-for-indexing #8216

Open
ahoppen opened this issue Jan 14, 2025 · 2 comments
Assignees

Comments

@ahoppen
Copy link
Member

ahoppen commented Jan 14, 2025

Running swift build --target HelloWorldHummingbirdServer --experimental-prepare-for-indexing on the attached project fails with

error: No target named 'swift-openapi-generator-arm64-apple-macosx15.0-debug-tool.exe' in build description

testpackage.zip

@plemarquand
Copy link
Contributor

I started digging in to this issue, and while I don't know if I've got enough context to fix it completely I can state my findings.

Building with --experimental-prepare-for-indexing triggers a LLBuildManifestBuilder.generatePrepareManifest(at:), which generates a stripped down manifest. This manifest generates compile commands and only creates .macro and .plugin product commands.

for description in self.plan.productMap {
// Need to generate macro products
switch description.product.type {
case .macro, .plugin:
try self.createProductCommand(description)
default:
break
}
}

Because swift-openapi-generator-arm64-apple-macosx15.0-debug-tool is an executable that is depended on by the OpenAPIGenerator plugin target, the product command for the plugin is added to the manifest but the executable that it depends on is not. If I comment out the switch and simply do a createProductCommand for all descriptions in the self.plan.productMap the build succeeds.

Obviously its not ideal, but I'm not sure the best approach to pair down the products while still building what is required.

The other, much more minor thing is the .exe in the target name on all platforms (i.e. macOS). It doesn't really break anything but is pretty confusing. That looks like a simple omission in the function that generates the executable product name:

fileprivate func executableName(
for product: String,
buildParameters: BuildParameters
) -> String {
"\(llbuildNameWithoutExtension(for: product, buildParameters: buildParameters)).exe"
}

Needs to take in to account the platform, i.e:

fileprivate func executableName(
    for product: String,
    buildParameters: BuildParameters
) -> String {
    if buildParameters.triple.isWindows() {
        "\(llbuildNameWithoutExtension(for: product, buildParameters: buildParameters)).exe"
    } else {
        "\(llbuildNameWithoutExtension(for: product, buildParameters: buildParameters))"
    }
}

@dschaefer2
Copy link
Member

Yup, I was adding in the plugins but not the plugin tools that they invoke. I'll look for a way to do that. I assume we'll want to run them so they can generate code for proper indexing.

@dschaefer2 dschaefer2 self-assigned this Jan 16, 2025
dschaefer2 added a commit to dschaefer2/swift-package-manager that referenced this issue Jan 17, 2025
Eliminate the special generatePrepareManifest and just reuse the real
one and add a couple of checks for the target/product prepareForIndexing
buildParameter instead. This then enables us to make sure we're doing
a full build of the plugin tools so they can generate code to be
properly indexed.

Addresses swiftlang#8216 for openapi generator.
dschaefer2 added a commit that referenced this issue Jan 21, 2025
Eliminate the special generatePrepareManifest and just reuse the real
one and add a couple of checks for the target/product prepareForIndexing
buildParameter instead. This then enables us to make sure we're doing a
full build of the plugin tools so they can generate code to be properly
indexed.

Addresses #8216 for openapi generator.
dschaefer2 added a commit to dschaefer2/swift-package-manager that referenced this issue Jan 21, 2025
…ng#8230)

Eliminate the special generatePrepareManifest and just reuse the real
one and add a couple of checks for the target/product prepareForIndexing
buildParameter instead. This then enables us to make sure we're doing a
full build of the plugin tools so they can generate code to be properly
indexed.

Addresses swiftlang#8216 for openapi generator.
dschaefer2 added a commit that referenced this issue Jan 22, 2025
…8236)

Back port of #8230 to release/6.1

Eliminate the special generatePrepareManifest and just reuse the real
one and add a couple of checks for the target/product prepareForIndexing
buildParameter instead. This then enables us to make sure we're doing a
full build of the plugin tools so they can generate code to be properly
indexed.

Addresses #8216 for openapi generator.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants