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

[Paul Smith]

On Wed, 2014-10-22 at 18:36 +0100, Philip Couling wrote:


> On 22 October 2014 15:07, Paul Smith <address@hidden> wrote:
>         You're correct that make doesn't care about the contents of files, but
>         you're incorrect when you say that make is only concerned with the 
> NAMES
>         of files.  Make is primarily concerned with the _MODIFICATION TIMES_ 
> of
>         files.  Make decides when a file is newer or older by checking its
>         modification time.  The name of the file is only useful to make 
> insofar
>         as it allows make to find the target's modification time.

> Agreed.
> Point of interest: symbolic links have a modification time separate to
> their referenced file.

I'm quite familiar :)

>         A file that doesn't exist does not have a modification time, and so 
> make
>         always considers that file to be out of date and rebuilds it.


> But I accept that make treats all links (dangling or otherwise) as
> transparent.
> I don't like it and would love to understand the reasoning behind that
> decision, but it does at least explain make's logic neatly.

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.

That means that in order to operate on the symlink itself, or even to
know that there IS a symlink, you have to use completely different
system calls (e.g., lstat(2)).  You have to (re)write the code
specifically to handle them.

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".

However, as I mentioned before there is always the -L flag, if you
really want make to treat symlinks separately from the files they point
to.

BTW:

> This results in errors because ln will not overwrite the link.

This is trivially solved by using "ln -s -f" instead of just "ln -s".