Re: Fwd: What is the logic behind make's handling of symbolic links?

[Philip Couling]

>
> Firstly, this is how the POSIX interface works.  All standard system
> calls that operate on files, including stat(2) which is how one
> retrieves the modification time, return information on the final file
> not the symlink (or an error if the symlink cannot be resolved).  The
> resolution of the symlink actually happens inside the filesystem (in the
> kernel), not in userspace.
>

lstat is part of posix also.
http://pubs.opengroup.org/onlinepubs/009695399/functions/lstat.html
But I see nothing in the standard to give preference to using stat over
lstat; nothing to guide you down one path or another.

But...

Secondly, because most of the time what you want to do with a target in
> make is to use it for some other purpose (compile it or link it or
> similar); to do these things you need to have the contents of the file.
> So make per se doesn't care about the contents, but 99% of the time the
> tools make is invoking DO care about the contents.  If make didn't
> rebuild that file then you'd get other errors from whatever command make
> invoked.  It seems like a very rare situation where you'd want to have
> make treat a broken symlink as a "successfully built target".
>
>
Reading this I now understand your earlier point about timestamps.
Your comment that targets are frequently used as dependencies highlights
the significance of this.
Now I'm convinced that make _should_ treat symlinks as transparent.
Consider:

foo: bar
    gcc -o foo bar

bar:
    ln -sf baz

If I edit baz, it's clear that foo should be rebuilt. So for this to work,
the symlink's time stamp must be evaluated as the referenced file.
>From the need for transparent links we can derive the behaviour around
dangling links.

Perfect. That's exactly what I was looking for.

Thanks Paul!