GeneratedMocks modified during Build Phase Xcode 13

[bratxdy]

Starting in Xcode 13 we started getting errors around Cuckoo that the GeneratedMocks file was modified during build time. It seems like this could be an Xcode 13 issue as it doesn't seem to be respecting Output Files, but is there anything you guys can do on your end to fix this? Or do you know of any tips for fixing this on the integration side? We've been using Cuckoo for a couple years and have never had issues until Xcode 13. We are using input files lists for the list of mocks we want and an output file for the GeneratedMocks class. Our build phase is right before the Compile Sources build phase.

[ngoc-minh-do]

I facing this issue too

[JavaAdam]

I have the same issue as others too. See for a workaround: https://stackoverflow.com/questions/69256241/xcode-13-error-input-file-was-modified-during-the-build

The official Apple feedback to me was to use build rules instead of build phases. They recommended to watch this here: https://developer.apple.com/videos/play/wwdc2021/10210/?time=379

But I think this does not match the requirements, because for Cuckoo we do not have different file extensions. So I could not define a fitting build rule to avoid the build errors. Either it was not working or the source swift files to be mocked were compiled twice. I am curious what will be the next answer from apple.

[bratxdy]

I have tried the workout in that Stackoverflow, but the issue still occurs using an xcfilelist for the output file. Will give that wwdc talk a listen and see if I can figure something else out.

[JavaAdam]

At the end the workaround does also not worked for me. But the error occurs more seldom.

[dhaval12593]

We are facing the same issue.

[mjholgate]

I think I may have figured this out. In our case we are not using Cuckoo, but it is likely a similar problem to what you are seeing.

At times we end with background builds happening (e.g. for Swift UI Previews), and if those run concurrently with our main build, sometimes this will cause the main build to spot that the background build has changed the file.

I think the problem is that the build phase is creating files in the shared source tree rather than the derived output folder. That being said, I'm not sure how to make a generated file in the derived output file be referenced from the xcode project :-(.

[dhaval12593]

Someone suggested we should add a pre build action to our scheme. But my script take a filelist as an input and generates an output file. Not sure how to get that done :/

[mjholgate]

The trick I think is to make sure all your output files from your script are written to somewhere within $(DERIVED_FILE_DIR).

So your input xcfilelist should normally contain files relative to $(SRCROOT), and your output xcfilelist should only contain files relative to $(DERIVED_FILE_DIR). This will ensure that each separate build instance writes only to its own files.

You can then add the output files to your target by navigating to:

/Users//Library/Developer/Xcode/DerivedData/-*/Index/Build/Intermediates.noindex/.build/Debug-iphonesimulator/.build/DerivedSources

Once you've added the files, make sure to open them in the file navigator and make sure they are accessed relative to build products:

This should mean that each build only accesses its own instances of files.

[mjholgate]

Except....the above doesn't work properly, because the project file still references the platform part of the path (Debug-iphonesimulator), so it doesn't work when building for the device or release builds. Gah 😿

[dhaval12593]

The workaround suggested here https://stackoverflow.com/questions/69256241/xcode-13-error-input-file-was-modified-during-the-build worked for me

[bratxdy]

The workaround suggested here https://stackoverflow.com/questions/69256241/xcode-13-error-input-file-was-modified-during-the-build worked for me

Which one?

[tomlokhorst]

I'm investigating the same issue for R.swift.

I think the issue is caused by the Indexer running at the same time as the build. Xcode 13 seems to execute Run Scripts during indexing as well.

The fix is to only run the code generator during builds, not indexing:

if [ $ACTION != "indexbuild" ]; then
  # your script here 
fi

[dhaval12593]

@bratxdy

Something that seems to work for both Xcode 12.5 and Xcode 13 is to add this to a cuckoo-output.xcfilelist (name it whatever you want) file:

${PROJECT_DIR}/${PROJECT_NAME}Tests/GeneratedMocks.swift
and add that xcfilelist to the Run Script's Output File Lists instead of adding the path to GeneratedMocks.swift directly in Output Files.

Hey Brady, Dhaval here.

[JavaAdam]

I'm investigating the same issue for R.swift.

I think the issue is caused by the Indexer running at the same time as the build. Xcode 13 seems to execute Run Scripts during indexing as well.

The fix is to only run the code generator during builds, not indexing:

if [ $ACTION != "indexbuild" ]; then
  # your script here 
fi

It seems that this works for me also. Thank you @tomlokhorst!

[TadeasKriz]

Thank you everyone for looking into it. @tomlokhorst could you please open a PR updating the run script in README? Thanks!

[tomlokhorst]

I’ve never used Cuckoo, and don’t know how it works. I suggest that somebody who actually knows the project checks if this works for your use case, and updates the documentation.

…

Op 8 okt. 2021 om 11:07 heeft Tadeas Kriz ***@***.***> het volgende geschreven:  Thank you everyone for looking into it. @tomlokhorst could you please open a PR updating the run script in README? Thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[TadeasKriz]

Oh I didn't know that and I didn't want to take your contribution away from you. I'll go ahead and update it then, thank you!

[TadeasKriz]

I've added it to the README's run script example, let me know if it works for y'all and then I'll go ahead and close this issue. Thanks everyone!

[bratxdy]

Hey @dhaval12593 , hope everything is going well! So we've been using that solution for several days now. It made the issue occur less often, but it still does occur with that solution in place.

@tomlokhorst thanks for the solution! It appears to be working, but I will let it soak for a couple days before I confirm that it is and will update @TadeasKriz and everyone here if we still are seeing the issue!

Thanks everyone.

[jazminebarroga]

Anyone else still experiences this issue even with the proposed solution?