polac24
commented
2 years ago Hello!
Because XCRemoteCache does not hardcode arm64 nor x86_64 and as you reported none of ENVs contain it, I bet a path to a non-existing directory is reported in the list of dependencies reported by the compiler in .d.
Assuming a target that fails with an error is DMLProto_Showdown and have arm64 does not exist , you can see which dependencies are reported by the compiler. I would verify that all of them exist:
find /Users/csignori/Library/Developer/Xcode/DerivedData/DMLProto_Showdown-fnyfbyrumovpfnfvglkwmudrshgr/Build/Intermediates.noindex/DMLProto.build/Debug-iphonesimulator/DMLProto_Showdown.build/Objects-normal/arm64/ -type f -name "*.d" | xargs grep -ohE "[^ ]+\/arm64\/[^ ]+"For x86_64 error, that would be:
find /Users/csignori/Library/Developer/Xcode/DerivedData/DMLProto_Showdown-fnyfbyrumovpfnfvglkwmudrshgr/Build/Intermediates.noindex/DMLProto.build/Debug-iphonesimulator/DMLProto_Showdown.build/Objects-normal/arm64/ -type f -name "*.d" | xargs grep -ohE "[^ ]+\/x86_64\/[^ ]+"
cezarsignori
My integration setup
[X] Automatic integration using
xcprepare integrate ...Expected/desired behavior
I expect deterministic and reproducible outcome from building my application in producer mode, particularly, I expect a successful build.
Minimal reproduction of the problem with instructions
Step 0. Generate xcworkspace and xcodeproj files via BUCK with ENVs overridden to arm64 only; Step 1. Integrate RC with the application via
xcprepare integrate ...; Step 2. Runrm -rf ~/Library/Developer/Xcode/DerivedDataandrm -rf ~/Library/Caches/XCRemoteCache; Step 3. Runrm -rf /tmp/cache/cacheon sample docker instance on localhost; Step 4. Build the app normally via Xcode; Step 5. Verify producer logs; Step 6. Repeat steps 2 to 5.I had one completely successful build without any errors in the logs and multiple other builds with randomly occurring errors.
Producer Logs
Environment
Post build stats
Others
I am on an Apple M1 Max with macOS Monterey 12.2.1 (21D62).
I am testing RC 0.3.7 on small application with 70 dependencies (across my own modules, git submodules and Pods committed to the repo).
Each xcodeproj has an associated manually created
.rcinfofile with the following content:primary_repo: {xcodeproj_repo} cache_addresses: - http://localhost:8080/cache primary_branch: csignori/xcremotecache-proto out_of_band_mappings: { 'TOOLS_BUCK-OUT':'/Users/csignori/Projects/iphone/tools/config/buck-out', 'CORE_MODULES_BUCK-OUT':'/Users/csignori/Projects/iphone/{root_project}/Modules/CoreModules/buck-out', 'BDUX_BUCK-OUT':'/Users/csignori/Projects/iphone/{root_project}/Modules/Platform/Bdux/buck-out', 'MISC_BUCK-OUT':'/Users/csignori/Projects/iphone/{root_project}/Modules/Miscellaneous/buck-out', 'PODS_BUCK-OUT':'/Users/csignori/Projects/iphone/Pods/buck-out', 'SUBMODULES_BUCK-OUT':'/Users/csignori/Projects/iphone/Submodules/buck-out', 'ROOT_BUCK-OUT':'/Users/csignori/Projects/iphone/buck-out', 'PODS':'/Users/csignori/Projects/iphone/Pods', }After I generate my Xcode files via BUCK, run
xcprepare integrate, build the app and check the producer logs I consistently see the following error multiple times (the number of occurrences vary slightly):Following instructions provided by @polac24 on #92, I added a build step exporting ENVs.
PLATFORM_PREFERRED_ARCHis indeed x86_64, but also in every other ENV arm64 is 1st in the list (e.g.,ARCHS).I also checked the other ENVs listed in #42 and for me these are their values:
And
LINK_FILE_LIST_normal_x86_64is not defined, as expected.From what I read on #33, #39 and #42, I should not be seeing this issue.
So I forced
PLATFORM_PREFERRED_ARCH = arm64to see if the problem would go away and even though the export run script build step shows the arm64 value, the RC log still shows the x86_64 errors.I then overrode all those ENVs so they don't contain x86_64 at all.
Now, I either get a successful build (rare) or a number these errors:
Note, before I had "x86_64" issues and now I most of the times have "arm64" issues.