@@ -201,6 +201,10 @@ While an implementation detail, it’s worth noting that in this approach, a
201
201
Clang sources. This extends to the ` MixedTargetDescription ` type in that it
202
202
wraps a ` SwiftTargetDescription ` and ` ClangTargetDescription ` .
203
203
204
+ Using this approach allows for greater code-reuse, and reduces the chance of
205
+ introducing a regression from changing existing sub-target types like
206
+ ` SwiftTarget ` and ` ClangTarget ` .
207
+
204
208
The role of the ` MixedTargetBuildDescription ` is to generate auxiliary
205
209
artifacts needed for the build and pass specific build flags to the underlying
206
210
` SwiftTargetBuildDescription ` and ` ClangTargetBuildDescription ` .
@@ -480,39 +484,17 @@ Additionally, this feature will be gated on a tools minor version update, so
480
484
mixed language targets building on older toolchains that do not support this
481
485
feature will continue to [ throw an error] [ mixed-target-error ] .
482
486
483
- ## Alternatives considered
484
-
485
- ### Provide custom implementations for ` MixedTarget ` and ` MixedTargetBuildDescription `
486
-
487
- As explained in the Detailed Design section, these two types effectively wrap
488
- the Swift and Clang parts necessary to define or build the target. One
489
- alternative approach was to provide custom implementations that did not heavily
490
- rely on code reuse of existing types. The deciding drawback of this approach
491
- was that it would have resulted in a lot of duplicated code.
492
-
493
- ### Consolidate target modeling logic so that all targets are ` MixedTarget ` s
494
-
495
- The deciding drawback here was the risk of introducing a regression in how
496
- Swift or Clang targets are built. A benefit of the chosen design over this
497
- alternative is that the code paths introduced in this proposal have little
498
- crossover with the existing code paths that build Swift or Clang targets–
499
- further reducing the chance of introducing an untested regression. However,
500
- this alternative should be considered as a future direction for the package
501
- manager. The chosen design offers a natural path to making all targets mixed
502
- source targets by default. The implementations from ` ClangTarget ` ,
503
- ` SwiftTarget ` , ` ClangTargetBuildDescription ` and ` SwiftTargetBuildDescription `
504
- can be bubbled up to the mixed target types accordingly. This alternative is
505
- listed in the Future Directions section as an area of future work.
506
-
507
487
## Future Directions
508
488
509
489
- Enable package authors to expose non-public headers to their mixed
510
490
target's Swift implemention.
511
491
- Investigate uses cases for extending mixed language target support to
512
492
currently unsupported types of targets (e.g. executables).
513
493
- Extend this solution so that all targets are mixed language targets by
514
- default. This refactor would simplify the current implementation of the
515
- package manager.
494
+ default. This could simplify the implemention as language-specific types
495
+ like ` ClangTarget ` , ` SwiftTarget ` , and ` MixedTarget ` could be consolidated
496
+ into a single type. This approach was avoided in the initial implementation
497
+ of this feature to reduce the risk of introducing a regression.
516
498
517
499
<!-- Links -->
518
500
0 commit comments