Follow-up Comment #1, bug #60960 (project make):

It's actually a very hard problem to know whether two paths are really the
"same file" or not.  That's why make uses a simple textual comparison and
leaves it at that (it does try one trivial simplification: it treats the
targets "./foo" and "foo" as the same).

If we were to limit ourselves to traditional POSIX-style filesystems then we
could use a combination of device ID and inode, which should be unique. 
However, it's not clear all other filesystems have similar facilities so
portability might be an issue.

Assuming we could come up with a portable way to uniquely identify that one
file was reachable via different paths, then it would probably not be too bad
to have make detect this situation at runtime, but only if it were actually
going to build both targets in the same instance of make.  We could just
remember the unique ID of all the targets we've already built and if we find a
different target with the same unique ID as one we have remembered, we could
write a warning or fail the build.  Then it would be up to users to fix their

You wouldn't get any notification if you only built one of the "duplicate"
paths and not the other in a given invocation of make.

I don't see any realistic way that make could magically coalesce two such
targets into one and "fix up" this mistake on its own.

Also, I'm pretty sure having make fail if it detected this situation would be
considered a violation of POSIX.

I will leave this enhancement request open for now, to think about.


Reply to this item at:


  Message sent via Savannah

Reply via email to