# RFC: External Build System Dependencies

**URL:** https://community.tuist.dev/t/rfc-external-build-system-dependencies/879
**Category:** RFCs
**Tags:** product
**Created:** [January 27, 2026, 3:34pm UTC](https://community.tuist.dev/t/rfc-external-build-system-dependencies/879 "2026-01-27T15:34:48Z")
**Posts on this page:** 1
**Showing post:** 2

<div class="post-metadata">

### Author: ![marekfort](https://community.tuist.dev/user_avatar/community.tuist.dev/marekfort/32/8_2.png) [@marekfort](https://community.tuist.dev/u/marekfort)
#### Post date: [January 29, 2026, 5:02pm UTC](https://community.tuist.dev/t/rfc-external-build-system-dependencies/879/2 "2026-01-29T17:02:20Z")

</div>

Thanks for the proposal! Generally very much aligned 🙂

> [@pepicrft](#):
>
> **Naming** : Is `.externalBuild()` the right name? Alternatives:

Yeah, that’s tricky. I was thinking whether it would make sense for the `externalBuild` to be just the underlying base model, but users would primarily define them with predefined factories from `ProjectDescription`, such as:

```auto
.kmm(modulePath: "../kmp/shared", configuration: .release)

```

I’m not sure how standard the tasks for building an xcframework via KMM are, though, so this may not make sense.

As for the naming itself, `external` evokes to me a third-party dependency, which is not the case here. What do you think about `foreignBuild`, similar to Bazel’s [rules\_foreign\_cc](https://github.com/bazel-contrib/rules_foreign_cc).

> [@pepicrft](#):
>
> **Error handling** : How should build failures surface?

I would start with passing the stderr to the Xcode build log.

> [@pepicrft](#):
>
> **Script vs path** : Should we also support referencing a script file instead of inline script?

We can start with an inline script. In the end, you can also call out to a script file, so it’s not like you’d be always forced to specify everything directly in the `Project.swift`.

---

_[View the full topic](https://community.tuist.dev/t/rfc-external-build-system-dependencies/879)._