Project lock file

[yonaskolb]

I've been thinking a bit about the workflow of branch switching when you use XcodeGen. Currently many people are regenerating the project after a checkout (sometimes in a git checkout hook) to make sure the project is up to date, in case the project spec has changed or files have been added or removed. In a very large project, this can potentially take a couple of seconds.

I propose adding a project lock file that is used to track whether generation is necessary.

1. Every time the project is generated, all the files it includes in the project are looped through and collected. These files would be things source files and xcconfig files. Then all these file paths along with the spec itself would be written to a project.lock file (name TBD).
2. A new argument can be added to xcodegen, something like --check-lock (name?). When this is provided it checks for a project.lock file and compares the current spec with the one included in the lock file.
   • if it's different generate the file
   • if it's the same then collect all the files in the current spec the same as it does when writing the lock file
   • if these files differ from what is in the lock file then generate

For those using Cocoapods, a pod install has to be run after project generation. Another argument --pod-install could run pod install after generation. This would mean it only runs if get past the lock file.

This command could then be added as a git checkout hook (perhaps with a command in XcodeGen itself)

Thoughts?

[ryohey]

Sounds good! I also want to use --pod-install.

However, since I think that it is also necessary to obtain a list of source files when generating projects and comparing project.lock, either way, it will take more time for more files.
I didn't measure precisely, as far as seen the log, are seen in our project it takes about 3 seconds for generating project and about 1 second for writing project. I am thinking that much time of project generation is used for scanning source files, so I am uncertain about how much we can improvements with lock file.

[LinusU]

I've personally solved this with a Makefile that have the Xcode project dependent on the project.yml file. Thus, every time that project.yml is edited, the Xcode project will be rebuilt before continuing with anything else.

Not saying that this shouldn't be a good addition ☺️ just sharing my current setup.

edit: I'm using something similar to: https://github.com/LinusU/Soon/blob/master/Makefile

[brentleyjones]

For us we have lots fo changes that aren't listed in the project.yml, such as moving/adding/removing of source files. This feature would be really nice for us.

[keith]

We currently solve this problem by:

1. Checking if the project definition has changed via diffing the sha256 of the file vs the last time we generated the project
2. Using git ls-files to see if any files have been added or deleted

For those interested this is our script for this:

#!/bin/bash

set -o pipefail
set -u

touch ./tmp/project_generated.json.sha256
shasum --check ./tmp/project_generated.json.sha256 > /dev/null 2>&1
project_changed=$?
shasum -a 256 ./project_generated.json > ./tmp/project_generated.json.sha256

git ls-files --others --exclude-standard --cached \
  | shasum -a 256 > ./tmp/newfiles.txt

cmp --silent ./tmp/files.txt ./tmp/newfiles.txt
files_changed=$?
mv ./tmp/newfiles.txt ./tmp/files.txt

test -f ./Lyft.xcodeproj/project.pbxproj
project_exists=$?

if [[ "$project_changed" -ne 0 ]] || [[ "$files_changed" -ne 0 ]] \
  || [[ "$project_exists" -ne 0 ]]
then
  exit 1
fi

The only known case this doesn't handle is if the dev changes the project in Xcode. I'm planning on solving that with the timestamp of the project.pbxproj in the meantime.

This proposal sounds great though!

[yonaskolb]

@keith that's an ok solution. The advantages here are:

1. if you use the include feature to pull in multiple specs this will check all for changes
2. less false positives on file additions and removals as not every file in the git repo contributes to the structure of the project, especially in large mono-repos
3. related to 2, if you pull in files from outside the base directory/repo they will still be tracked

I've put up a working implementation here #412. Let's continue the conversation there

[yonaskolb]

If you guys could give it a test that would be great! 😄

[keith]

I'll try this out on ours shortly!

…

-- Keith Smiley

On Sat, Sep 29, 2018 at 12:15 AM Yonas Kolb ***@***.***> wrote: If you guys could give it a test that would be great! 😄 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#409 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARU7tVlgaXynrX3IejBBuCrygSCezz6ks5ufx4jgaJpZM4W6fAp> .

[yonaskolb]

Released in 2.1.0 under a --use-cache flag