Hi Paul, > It's done so that if you write: > > foo: bar/ > > in one place in your makefile, and: > > bar: biz > > another place, and: > > boz: $(CURDIR)/bar > > in a third place, make realizes they are all the same target and won't > try to build them multiple times (or, say "don't know how to build ..." > for one or more of them).
Well, on the one hand, I tend to agree it makes sense since on the file system level foo and foo/ are the same (well, if foo is a directory, to be precise). On the other had, implicit rules in make are based on the ability to identify a constant prefix or suffix that determines a type of a target (e.g., '.c' implies that it's a C source file, etc). Thus, by stripping trailing slash, make disables the use of quite a natural suffix that could be used to 'typify' directories. Therefore, it is not clear to me that doing so is a right thing to do. But, anyway, it is not for me to decide... > bk> For example, $(dir) does not strip the trailing slash. Oh, but $(@D) > bk> does... > > These are user functions. I'm talking about make's internal > representation of the target name, that it uses to walk the DAG. I was just trying to point out that GNU make's way of dealing with directories is not very consistent. hth, -boris
signature.asc
Description: Digital signature
_______________________________________________ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
