[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:

  

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

Metaprogramming Make (was: Static pattern rules with more than one '%')

[Alejandro Colomar]

Hi Paul,

On 2023-08-31 02:42, Paul Smith wrote:
> On Thu, 2023-08-31 at 00:08 +0200, Alejandro Colomar wrote:
>> I ended up using $(foreach ... $(eval ...)).  I didn't know about
>> $(eval) before reading Paul's troubleshooting guide, and it was mind
>> opening.  It solves a limitation I thought GNU Make had but really
>> hadn't.  :)
> 
> You might want to read this set of blog posts; start with the bottom
> one as it was posted first.
> 
> https://make.mad-scientist.net/category/metaprogramming/

Sure :)

I found a bug there.  In chapter V, there's this code:

ifeq (,$(filter clean clean-%,$(MAKECMDGOALS)))
  -include rules.mk
endif


I believe you meant to use $(filter-out ...).

BTW, I found Paul's First Rule (which I had been trying to quote a few times
but didn't find where I had read that in the past) thanks to this.  :-)

Cheers,
Alex

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5



OpenPGP_signature
Description: OpenPGP digital signature