- Building Tuist when opening it Natively in Xcode (double clicking the Package.swift) yields a few buidl errors
- This is due to missing explicit dependencies between targets
Test Plan:
- Open the Package.swift to launch it in Xcode
_Note: even with this fix it doesn't seem the ProjectDescription framework/dylib is being built correctly in this mode, the current workaround is to continue to use `swift package generate-xcodeproj`_
- The project generation process was replacing the entire `.xcodeproj` and `.xcworkspace` directories
- This lead to wiping all previous contents within those directories
- This included a nested `xcuserdata` directory which is usually gitignored and holds the Xcode UI state
- To reoslve this, only a the individual files are replaced rather than the entire directory
Test Plan:
- Run `tuist generate` within any fixture
- Open the generated project
- Navigate around, set breakpoints
- Re-order one of the source files (i.e. to cause a re-generation)
- Close Xcode
- Run `tuist generate` again
- Open the generated project
- Verify the last viewed file is opened automatically, breakpoints, the recently viewed files list are all still there
### Short description
We've noticed the scheme generation is not always stable. The order of testable targets in a scheme could change after re-generating the project.
It's reproducible when multiple testable targets depend on the same target (framework, or app) within a single project.
i.e.
- ProjectA:
- AppTarget
- UnitTestsTarget (dependencies: [AppTarget])
- UITestsTarget (dependencies: [AppTarget])
### Solution
- Sorted testable targets
- Updated one of the unit tests to reproduce the issues, and avoid regression in the future
- Updated the integration tests to cover multiple testable targets user case
Resolves: https://github.com/tuist/tuist/issues/660
- Ensure the `LD_RUNPATH_SEARCH_PATHS` build setting is set for test targets
Test Plan:
- Generate `fixtures/ios_app_with_tests`
- Verify the generated project's test target contains a valid `LD_RUNPATH_SEARCH_PATHS` build setting
* Delete embed logic
* Add methods to read the dsym path & bcsymbolmap paths from a framework
* Place the tests in the right test case
* Implement EmbedScriptGenerator
* Test EmbedScriptGenerator
* Extract methods that interact with the system into metadata provider utilities and fix tests
* Include output paths
* Test FrameworkMetadataProvider
* Test PrecompiledMetadataProvider
* Add more tests
* Create fixture project
* Add acceptance test
* Address comments
* Use Xcode 11.1
* Update Package.resolved
* Update XcodeProj
* Make the tuistenv install test more resilient
* Add System.shared
* Implement TuistTestCase, TusitUnitTestCase, and refactor all the tests to use those classes instead.
Make some progress
Refactor tests to use TuistUnitTestCase
Create TuistTestCase
* Fix some tests
* Update the documentation to indicate that there is more than one integration tests target
* Update the CHANGELOG
* Indicate the product that we build for release
* Remove unnecessary methods
Marek Fořt