* Fix "Embed Frameworks" build phase parameters
Resolves: https://github.com/tuist/tuist/issues/2153
- Generated projects had a missing empty `dstPath` parameter for the "Embed Frameowkrs" build phase
- This was discovered while comparing projects where the same phase was added by Xcode (via the UI when embedding frameworks)
- This small mismatch in parmeters results in build failures when linking against Swift Package binary dependencies
- Adding a new fixture that depends on a binary dependency (FirebaseAnalytics)
Test Plan:
- Run `swift build && swift run tuist generate --path fixtures/ios_app_with_remote_binary_swift_package`
- Verify the generated project builds
* Switch fixture to local package with binary target
* Update change log
* Use the build phase to locate the built product artifacts
* Add acceptance test
* Fix integration tests
* Fix acceptance tests
* Fix acceptance test
* Fix cache acceptance tests
* Fix watchOS acceptance tests
* Fix acceptance test
* Run pipelines on Xcode 12.1
* Remove Carthage test
* Run acceptance tests with Xcode 11.5 too
* Fix acceptance test with widget
* [cache_improvements] Adds a --withDevice flag to exclude simulator builds by default when running
* [cache_improvements] Fix tests
* Change the argument description
* Fix acceptance tests
* Add documentation
* Change the short and long keywords for the command
* Fix acceptance tests
* Fix acceptance tests and rename --with-device to --include-device-arch
Co-authored-by: Pedro Piñera <pepibumur@gmail.com>
When a project has a scheme that runs multiple test targets that rely on
the `Embed Precompiled Frameworks` script then the new build system
fails because there are multiple commands that produce the same target
file.
This commit prevents adding symbol files to the input/output file lists
for test targets to prevent this error from occuring.
Fixestuist/tuist#919
Kas