Subject: Resolving paths within symlinked dirs (Re: Support for virtual targets)

From: Jan Niklas Böhm <[email-masked]>
Date: Sun, 17 Apr 2022 22:37:21 +0200

Thanks for the answer, that does make things much clearer!  I will then 
change my approach in order to create a file instead of relying on the 
apenwarr/redo-specific behavior.  Thanks for the detailed explanation!

> So in goredo you can create both real "phony" targets (without producing
> any output) and "virtual" targets (by making an empty file).
> apenwarr/redo lacks "phony" targets possibility (except for additional
> redo-always invocation). Phony targets are used mainly for targets like
> "all"/"install" in practice, so as a rule they are called manually with
> "redo" command, not redo-ifchange, and that is why they are forcefully
> run anyway, like an ordinary phony-target should do. "Virtual" targets,
> with explicit "touch $3" are also portable across apenwarr/redo, redo-c
> and similar implementations -- so hardly there are any portability issues.

Now I do agree that this is the more sensible behavior of the program, I 
was not aware that this is inherited from how Makefiles operate.

This actually send me down a rabbit hole as the target was still 
perpetually ood despite creating an output file in the former 
virtual/phony do file.  I think I have chased down the problem after 
investigating this for a good part of today (and in hindsight it is 
probably trivial).  The issue is that source files are not always 
correctly resolved when redo-ing files in symlinked directories.  I hope 
the following MWE illustrates the problem.

	$ mkdir -p three/folders/deep
	$ ln -s three/folders/deep symlink
	$ export DIR=`pwd`
	$ mkdir elsewhere
	$ echo foo > elsewhere/srcfile
	$ cat << EOF > three/folders/deep/target.do
redo-ifchange $DIR/elsewhere/srcfile
cat $DIR/elsewhere/srcfile
EOF

When going into the directory “three/folders/deep”, and typing “redo 
target” everything works as expected.  But when cd-ing into the folder 
“symlink”, the target will always be considered out of date; since it is 
non-existent.

 From what I understand the issue is that the absolute path is converted 
to a relative path, which is relative to the proper directory.  On the 
other hand, the symlink then has a different nesting depth and resolving 
the relative path from the symlinked directory will point to a 
non-existent file; hence the target being ood.

This problem is not related to the initial mail and obviously virtual 
targets would not help here.  I am not entirely sure on what would be 
the best approach in order to correct this behavior, maybe the cwd can 
be resolved through the file system prior to checking for ood targets.

I hope the example is illustrative, I can try and expand on the issue, 
should that be necessary.  Thanks for the quick response and nice 
explanation in the first place!