> > 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! _______________________________________________ Help-make mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-make
