Feature Request: Xcode project lock file

[luispadron]

Consider some lockfile-like mechanism which can ensure to some degree when the project needs to be regenerated.

There are times when the project needs to be re-generated, to get BUILD file changes, target changes, etc. It would be good to have the build fail with some warning when this is detected to be required.

This will better surface errors that would be fixed by a regeneration.

[brentleyjones]

Interestingly we had various forms of this over time, but it was just when it was absolutely needed (such as target ids changing, so builds wouldn't do what you expected). It's now down to a single check: https://github.com/MobileNativeFoundation/rules_xcodeproj/blob/f3a9cf3587d9968ef3a7d833d072b2ecac0c6404/xcodeproj/internal/templates/bazel_build.sh#L131-L161

Some of the previous checks were expensive to calculate, so I'm glad they are gone. A benefit of BwB mode is that you don't need to regenerate for a lot of reasons, the build will still work. Technically some changes will lead to indexing being off until a regen though. I feel that any check that would satisfy this request would be pretty sensitive: if the project would change at all, it would throw a warning. I guess if it's opt in, that's fine, but I'm not sure that anyone would actually want to use it? (though if it could be a warning versus a failure, maybe?)

[luispadron]

A benefit of BwB mode is that you don't need to regenerate for a lot of reasons

Ah well then thats even better, our users tend to think they need to regenerate a lot because they're used to old CocoaPods style changes to spec causing invalid projects if not re-generated. We'll just need to work on education here.

If we already handle the cases where the build will be fine, then I don't think I'd need anything else personally so thank you for clarifying!

[brentleyjones]

Please do let me know, by a comment here, if you run into any situations where a project regen did fix a build. I only know of one, where the rules_xcodeproj dependency itself was updated, causing a mismatch on the generated BUILD file and the ruleset. Outside of that, the above check catches other changes.

[brentleyjones]

I found one. If you delete the /private/var/rules_xcodeproj directory (or the system deletes it for you...), you'll get an error like this:

ERROR: Skipping '@@_main~internal~rules_xcodeproj_generated//generator/tools/xcodeproj:xcodeproj': no such package '@_main~internal~rules_xcodeproj_generated//generator/tools/xcodeproj': BUILD file not found in directory 'generator/tools/xcodeproj' of external repository @_main~internal~rules_xcodeproj_generated. Add a BUILD file to a directory to mark it as a package.
WARNING: Target pattern parsing failed.
ERROR: no such package '@_main~internal~rules_xcodeproj_generated//generator/tools/xcodeproj': BUILD file not found in directory 'generator/tools/xcodeproj' of external repository @_main~internal~rules_xcodeproj_generated. Add a BUILD file to a directory to mark it as a package.

We should add something to bazel_build.sh to detect this and call for a regen.

[brentleyjones]

@cgrindel the error above is similar to the one you saw in your rules_swift_package_manager integration tests. What was causing it for you?

[cgrindel]

Interesting. I have not chased it down. The PR merged because I updated it with the latest from main, which upgraded Bazel to 7.1.0.

This is the test script for the example that was failing. Could there be some weird interaction with cached files? I am struggling to understand why the problem went away with the Bazel upgrade.