[bug #42270] Make needs to canonicalise paths

[Kaz Kylheku]

Follow-up Comment #2, bug #42270 (project make):

The bug wasn't opened by someone looking to have symlinks resolved, but that's
what will happen if you canonicalize paths.

Applications must assume that symbolic links belong to the user and not expand
them, unless somehow explicitly requested.

Applications that canonicalize path names and expand symbolic links do wrong,
annoying things, such as put files into the wrong directories.

Suppose we have a file

  src/parser.c -> ../../foo-project/src/parser.c

When we build parser.c we want parser.o to be right here based on editing
src/parser.c to src/parser.o.

Suppose the build system canonicalizes the path, turning src/parser.c into
/home/bob/foo-project/src/parser.c. And then calculates the .o file from that?
We end up with the object file going to  ../../foo-project/src/parser.o where
we don't want it.

Symbolic links are something **the user set up to fool the application**.

Applications should cooperate and **stay fooled**.

I think the right position in Make is that if the user has used symbolic links
(or any other path mechanism like ".." and "." links or absolute versus
relative) such that they refer to the same file using two different paths,
that's their problem; it's pretty easy to avoid, and avoiding that will almost
certainly improve the clarity of the Makefile.

GNU Make has all the tools: it has $(realpath ...) and $(abspath ...); it's up
to the Makefile programmer to decide whether either of these should be used
and how, and avoid situations when accessing the same thing using two or more
paths causes a problem.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?42270>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/