I have been running tests with tuist test and every now and then I will get build failures that says Module file '/.../Module-###.pcm' was validated as a system module and is now being imported as a non-system module; any difference in diagnostic options will be ignored. (The Module-###.pcm is not called like this, “Module” is the name of a module in the project, and the path to it is in the derived data’s ModuleCache.noindex directory)
I don’t know how to reproduce as it is flaky, but I’ve seen it occur on a clean derived data directory (cleaning it helps get pass it, if I don’t clean it will always fail). The project where this is happening is quite large and private so I don’t think I can produce a smaller example that would reproduce the issue. It’s also worth mentioning, building the app target always succeeds if I keep the derived data path separate for app builds and tests.
Expectation
I expect calls to tuist test to have successful builds every time without flakiness.
This doesn’t happen when building tests from our current project generation setup (XcodeGen).
Context
Tuist version: 4.41.0
Reproduction (mandatory for problems)
tuist test AllModules ← AllModules is an aggregated scheme with all module targets. This will produce flaky results, and fail with the mentioned error:
`Module file '/.../Module-###.pcm' was validated as a system module and is now being imported as a non-system module; any difference in diagnostic options will be ignored`
Yes, it also happens running xcodebuild build-for-testing on the generated workspace.
This is where I am at a loss. Xcode is the one generating the pcm files but we’re not indicating it to do so anywhere. The fact that is has the name of a module and a hash seems to indicate it is from a module, but this is at least not happening intentionally. I also don’t know why any of these modules would at any point be validated as system modules (or maybe I misunderstand what a “system module” means).
I was using binary caching. I was going to try disabling it, but now I have an even weirder issue where tuist test will always fail because it can’t find the simulator device. I’m using -destination "id=..." and this works with xcodebuild but it’s not with tuist.
You can either run the command with --verbose or in the latest Tuist version, we print the path to the logs that you can open in the Console.app. That way you can see the exact xcodebuild command we’re using.
If you think this is a Tuist issue, it’d be amazing if you could create an issue, ideally, with a reproducible sample.
This is where I am at a loss. Xcode is the one generating the pcm files but we’re not indicating it to do so anywhere. The fact that is has the name of a module and a hash seems to indicate it is from a module, but this is at least not happening intentionally. I also don’t know why any of these modules would at any point be validated as system modules (or maybe I misunderstand what a “system module” means).
Pulling in @waltflanagan and @pepicrft – do either of you know what are the conditions for when .pcm files are generated by Xcode? Any idea why the error mentioned in the original post could be happening?
I’ve been trying to find a way to reproduce it. Unfortunately today I woke up to see the issue completely gone. However, yesterday when it was consistently failing due to the device’s ID, it was immediately removed (and back to the pcm error) when I removed the -derivedDataPath argument. Worth mentioning that I have been cleaning derived data from the regular place and the custom ones every single time since I started testing this. Anyway, even if I add -derivedDataPath again, the UDID error won’t show up.
So I’m back to the pcm error, which seems to consistently show up whenever I run tuist test after build+testing using xcodebuild (because I’m emulating what we’re doing on CI, I’m running xcodebuild build-for-testing and then xcodebuild test-without-building). I’m also cleaning derived data in between these tasks.
I’ll keep looking for a way to reproduce this in a smaller project.
We’re cleaning tuist clean and cleaning derived data every time and this seems to be working. It’s a shame because doing this adds about 5 minutes of test time on CI every time. We don’t have any concrete knowledge on the reason for this, all we know is that the .pcm files is something that could be produced by Xcode 16 after their changes to explicit modules and dependency scanning.
