Skip to content

feat: add foreign build support#495

Merged
fortmarek merged 7 commits intomainfrom
foreign-build-support
Feb 13, 2026
Merged

feat: add foreign build support#495
fortmarek merged 7 commits intomainfrom
foreign-build-support

Conversation

@fortmarek
Copy link
Member

@fortmarek fortmarek commented Feb 10, 2026

Summary

Add graph model support for foreign build system dependencies (KMP, Rust, CMake, etc.):

  • Add ForeignBuildInfo model with script, inputs, and output artifact
  • Add ForeignBuildInput enum (.file, .folder, .script) for cache inputs
  • Add ForeignBuildArtifact enum (.xcframework, .framework, .library) for build outputs
  • Add Target.foreignBuild property and Target.isAggregate computed property
  • Add GraphDependency.foreignBuildOutput case for linking resolution
  • Remove old TargetDependency.foreignBuild indirect case in favor of the new model

Companion PR

Test plan

  • test_codable_foreignBuild verifies Codable round-trip
  • test_filtering verifies condition and withCondition
  • Full integration tested via tuist repo companion PR

🤖 Generated with Claude Code

fortmarek added a commit to tuist/tuist that referenced this pull request Feb 10, 2026
Add `.foreignBuild()` dependency type that wraps binary dependencies with
build instructions and cache inputs, enabling Tuist's module caching and
selective testing to work with artifacts from external build systems
(KMP, Rust, CMake, etc.).

- Add `CacheInput` type to ProjectDescription
- Add `foreignBuild` case to TargetDependency across all layers
- Add `ForeignBuildCacheInputHasher` for content hashing of cache inputs
- Add `ForeignBuildGraphMapper` that transforms foreign builds into
  synthetic script targets + binary dependencies
- Wire mapper into GraphMapperFactory pipeline
- Update all exhaustive switches to handle the new case

Depends on: tuist/XcodeGraph#495

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@fortmarek
Copy link
Member Author

Closing this PR — it's no longer needed.

The tuist PR (#9400) was refactored from the dependency-based approach (TargetDependency.foreignBuild) to a target-based approach (Target.foreignBuild() factory). As a result:

  • ForeignBuildCacheInput and TargetDependency.foreignBuild from this PR are not referenced anywhere in the tuist codebase
  • The tuist PR instead uses ForeignBuildInfo, ForeignBuildInput, and ForeignBuildArtifact as separate models on Target, along with GraphDependency.foreignBuildOutput for linking
  • The switch statement updates in TargetDependency+Extensions.swift and TargetDependency+GraphMapping.swift are for a case that would never be constructed

This PR is a leftover from the dependency-based approach that was abandoned in favor of the cleaner target-based design.

@fortmarek fortmarek closed this Feb 12, 2026
@fortmarek fortmarek reopened this Feb 12, 2026
@fortmarek fortmarek changed the title feat: add foreignBuild case to TargetDependency feat: add foreign build support Feb 12, 2026
@fortmarek fortmarek marked this pull request as ready for review February 13, 2026 09:18
@fortmarek fortmarek requested a review from pepicrft February 13, 2026 09:18
@dosubot dosubot bot added the size:L This PR changes 100-499 lines, ignoring generated files. label Feb 13, 2026
@dosubot
Copy link

dosubot bot commented Feb 13, 2026

Related Documentation

Checked 1 published document(s) in 1 knowledge base(s). No updates required.

How did I do? Any feedback?  Join Discord

@dosubot dosubot bot added the enhancement New feature or request label Feb 13, 2026
public var isPrecompiled: Bool {
switch self {
case .macro: return true
case .foreignBuildOutput: return true
Copy link
Contributor

Choose a reason for hiding this comment

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

Isn't the output of a foreign-built one of the existing types? (i.e. .xcframework, .library, or .library). If so, but we need to know it's from a foreignBuildOutput, can't we adjust the existing cases?

Copy link
Member Author

Choose a reason for hiding this comment

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

Same as here: tuist/tuist#9400 (comment)

For the foreign build, we don't know everything about the .xcframework in advance.

fortmarek and others added 5 commits February 13, 2026 11:39
Add support for foreign build system dependencies (KMP, Rust, CMake, etc.)
by introducing a new `foreignBuild` case on `TargetDependency` and a
`ForeignBuildCacheInput` model for content hashing.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…dInput, and ForeignBuildArtifact

Replace TargetDependency.foreignBuild case with Target.foreignBuild property
using dedicated ForeignBuildInfo, ForeignBuildInput, and ForeignBuildArtifact
types. Add GraphDependency.foreignBuildOutput for linking resolution.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…fact

Rename `ForeignBuildInfo` to `ForeignBuild` to match the ProjectDescription
naming convention. Nest `ForeignBuildInput` and `ForeignBuildArtifact` as
`ForeignBuild.Input` and `ForeignBuild.Artifact` for cleaner namespacing.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Remove .framework and .library cases from ForeignBuild.Artifact.
XCFramework is the only supported output format for foreign builds
as it provides multi-architecture support and cache compatibility.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The foreignBuild case was removed from TargetDependency (it moved
to the Target model), but the test file still referenced it.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@fortmarek fortmarek force-pushed the foreign-build-support branch from 024fde1 to 7c8db3f Compare February 13, 2026 10:40
fortmarek and others added 2 commits February 13, 2026 15:54
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@fortmarek fortmarek merged commit 4a32d7b into main Feb 13, 2026
7 checks passed
@fortmarek fortmarek deleted the foreign-build-support branch February 13, 2026 15:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request size:L This PR changes 100-499 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants