--no-environ-check doesn't seem to prevent the PATH check; should it?
Closed this issue · 5 comments
I have a node.js version manager installed in my shell called fnm which changes my PATH every terminal session. This causes tup to rebuild stuff pretty aggressively. I tried to work around it with --no-environ-check, but that doesn't seem to work. Does --no-environ-check only work for import/exported env vars?
$ tup --no-environ-check build-linux
[ tup ] [0.000s] Scanning filesystem...
[ tup ] [0.008s] Reading in new environment variables...
Environment variable changed: PATH
- Old: '/tmp/fnm_multishells/74726_1655075311477/bin:/home/suchipi/.local/bin:[redacted]'
- New: '/tmp/fnm_multishells/5863_1655338586388/bin:/home/suchipi/.local/bin:[redacted]'
I'm having trouble reproducing this. It looks like --no-environ-check should set the environ_check variable to 0 in the env_cb() function where it gets used. It should hit this block (
Line 5153 in c8bca8d
match = 1, so the block that prints out the Environment variable changed flag gets skipped. Here's a small test case I was using to try to test it:
$ cat build-linux/tup.config
$ cat foo.c
$ cat run.sh
PATH=$PATH:/home/marf/bin tup --no-environ-check build-linux
PATH=$PATH tup --no-environ-check build-linux
$ cat Tupfile
: foreach *.c |> gcc -c %f -o %o |> %B.o
When running run.sh I see:
[ tup ] [0.000s] Scanning filesystem...
[ tup ] [0.000s] No tup.config changes (environment check disabled).
[ tup ] [0.001s] No Tupfiles to parse.
[ tup ] [0.001s] No files to delete.
[ tup ] [0.001s] No commands to execute.
[ tup ] [0.001s] Updated.
[ tup ] [0.000s] Scanning filesystem...
[ tup ] [0.000s] No tup.config changes (environment check disabled).
[ tup ] [0.001s] No Tupfiles to parse.
[ tup ] [0.001s] No files to delete.
[ tup ] [0.001s] No commands to execute.
[ tup ] [0.001s] Updated.
With the --no-environ-check flag removed, each invocation in run.sh recompiles the .c file. What version of tup are you using? Does that test case behave differently for you?
I'm running tup 0.7.8-3 [debian], installed from my repo's package manager.
That test case behaves differently for me, yeah. I made a repo with that test case here to make sure it's the same as what you were testing:
https://github.com/suchipi/tup-463-repro
The behavior:
$ cat run.sh
#!/usr/bin/env bash
PATH=$PATH:$HOME/bin tup --no-environ-check build-linux
PATH=$PATH tup --no-environ-check build-linux
$ ./run.sh
[ tup ] [0.004s] Scanning filesystem...
[ tup ] [0.009s] Reading in new configuration/environment variables...
0) new variant: build-linux/tup.config
[ ] 100%
[ tup ] [0.013s] Parsing Tupfiles...
0) [0.001s] build-linux
[ ] 100%
[ tup ] [0.014s] No files to delete.
[ tup ] [0.014s] Generating .gitignore files...
[ tup ] [0.018s] Executing Commands...
0) [0.008s] build-linux: gcc -c foo.c -o foo.o
[ ] 100%
[ tup ] [0.030s] Updated.
[ tup ] [0.000s] Scanning filesystem...
[ tup ] [0.000s] Reading in new environment variables...
Environment variable changed: PATH
- Old: '/tmp/fnm_multishells/7997_1655955891101/bin:/home/suchipi/.local/bin:/opt/pipewire/bin:/opt/ffmpeg-static:/home/suchipi/.docker/cli-plugins:/home/suchipi/.fnm:./node_modules/.bin:/home/suchipi/.cargo/bin:./bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/opt/thinlinc/bin:/home/suchipi/bin'
- New: '/tmp/fnm_multishells/7997_1655955891101/bin:/home/suchipi/.local/bin:/opt/pipewire/bin:/opt/ffmpeg-static:/home/suchipi/.docker/cli-plugins:/home/suchipi/.fnm:./node_modules/.bin:/home/suchipi/.cargo/bin:./bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/opt/thinlinc/bin'
[ tup ] [0.005s] No Tupfiles to parse.
[ tup ] [0.007s] No files to delete.
[ tup ] [0.010s] Executing Commands...
0) [0.007s] build-linux: gcc -c foo.c -o foo.o
[ ] 100%
[ tup ] [0.021s] Updated.
$
I just compiled 0.7.11 and it works fine now 😅 sorry! Thanks for your help. I should have known to check for a newer version first, lol...
For future readers: I had to switch from fuse to fuse3 to make 0.7.11 work (using a Debian/Ubuntu-based distro)
No worries, glad you figured out the issue! And yes, fuse3 is now the default, although you can still configure tup to build with regular fuse (v2) by setting CONFIG_TUP_SERVER=fuse in tup.config when building tup itself.