tup runs full graph when file is modified which no other file depends on, with macFUSE on M1
petemoore opened this issue · 1 comments
This is a really bizarre one, and I've tried to create a simpler test case to demonstrate it, but I haven't been able to reduce it to something simpler.
To reproduce (on macOS 12.4 with Apple M1 Max):
$ git clone https://github.com/spectrum4/spectrum4
$ cd spectrum4
$ git checkout 3a60898253fbf1bdbc1af01972ed166078c38c67 # just a reference to the current HEAD as of now
$ tup # everything builds ok
$ tup # recognises there are no changes, does nothing - all fine so far
$ touch dev-setup/check-env.sh # no files depend on this one
$ tup # the entire DAG is rerun, even though no rules have `dev-setup/check-env.sh` as an input
Now what is strange, is that if I run the exact same workflow under docker (there is a tup-under-docker.sh
script in my repo that calls tup
inside a docker container with all required toolchains), everything behaves correctly, and touching dev-setup/check-env.sh
does not cause the full graph to be rerun. Instead, when running under docker, everything works as expected. Which makes me wonder if it might be an issue with the macFUSE integration... I therefore assume everything probably works fine running under linux natively too (although I haven't tried).
Note, the only rule that involves check-env.sh
is a format/linting check, that doesn't generate any files, but just returns with a none zero exit code if the file isn't formatted correctly.
I tried with an older version of tup
, and behaviour is the same there too, so doesn't seem to be a new problem.
Here is the graphviz file, if that helps:
Let me know if you would like e.g. a tar.gz of the .tup directory, if that helps, or if there is anything I can do to make troubleshooting easier.
Note, I also blew away the .tup directory to see if I just had a corrupted DB, but that didn't help.
If you happen to have a Mac and want to see if you can reproduce, there is a bootstrapping script to install the macOS toolchains that may be useful.
I suspect it is easier though if I just send you what you need from my computer.
Also happy to meet up to do a screen share etc, in case that helps. It is a weird one.
Thanks Mike!
This was due to go 1.18 calling git status
under the hood which read all files from the repo.
Fixed in spectrum4/spectrum4@dc584f0
Sorry, this wasn't a tup issue, it was a go issue really. I don't see a reason that go should call git status
without specifying a subdirectory in the repo.
I didn't see it in docker, because in my docker container, git isn't installed, so go build
wasn't calling it.