Skip to content

Conversation

@nikeokoronkwo
Copy link
Contributor

@nikeokoronkwo nikeokoronkwo commented Nov 18, 2025

Fixes #2792

Swiftly proxies commands to some of the tools that ship with Swift distributions, including: clang, ld.lld, and other tools. Therefore, such tools are symlinks to swiftly, and running swiftly directly would therefore not work when bundling assets.

This PR adds support for using package:native_toolchain_c on macOS with Swiftly installed, defaulting to the user's default installation of ar and ld where applicable.

I assume that in realistic use-cases, users would want to use specific toolchains and therefore, would want to use tools together rather than distinct instances of certain tools (i.e. prefer ld bundled with the currently resolved clang than a separate use of ld), and most users would prefer using the Clang distribution they already have in their system rather than that bundled with Swiftly, so I'm considering a separate PR for using a different clang toolchain than that Swiftly has. It would require some additions to current tool resolving and behavior, so I was considering it on a separate PR than this one.

Swiftly proxies commands to some of the tools that ship with Swift distributions, including: `clang`, `ld.lld`, and other tools. Therefore, such tools are symlinks to `swiftly`, and running `swiftly` directly would therefore not work when bundling assets.

This PR adds support for using `package:native_toolchain_c` on macOS with Swiftly installed, defaulting to the user's default installation of `ar` and `ld` where applicable.
@nikeokoronkwo nikeokoronkwo changed the title [native_toolchain_c] Fix clang compiler search + tools for Swiftly [native_toolchain_c] Fix clang compiler search + tools when using swiftly Nov 18, 2025
Copy link
Collaborator

@dcharkes dcharkes left a comment

Choose a reason for hiding this comment

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

Thanks @nikeokoronkwo !

It would require some additions to current tool resolving and behavior, so I was considering it on a separate PR than this one.

👍

If it is possible to have swiftly on the CI here in GitHub, you could consider adding an extra github workflow that covers it. We also run the CI an extra time in .github/workflows/native_toolchain_c.yaml to cover a different toolchain than the default ones.

And also, please add some tests that tools don't resolve at all on Linux/Windows.

(And version + changelog entry so I can hit publish after merging 😄)

@github-actions
Copy link

PR Health

License Headers ✔️
// Copyright (c) 2025, the Dart project authors. Please see the AUTHORS file
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
Files
no missing headers

All source files should start with a license header.

Unrelated files missing license headers
Files
pkgs/objective_c/lib/src/ns_input_stream.dart

This check can be disabled by tagging the PR with skip-license-check.

API leaks ✔️

The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.

Package Leaked API symbol Leaking sources

This check can be disabled by tagging the PR with skip-leaking-check.

Breaking changes ✔️
Package Change Current Version New Version Needed Version Looking good?
native_toolchain_c None 0.17.4 0.17.4 0.17.4 ✔️

This check can be disabled by tagging the PR with skip-breaking-check.

Changelog Entry ✔️
Package Changed Files

Changes to files need to be accounted for in their respective changelogs.

This check can be disabled by tagging the PR with skip-changelog-check.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[native_toolchain_c] Error finding clang compiler with swiftly installed, uses swiftly executable instead

2 participants