On Fri, Aug 29, 2008 at 2:59 PM, Eduardo Suárez <[EMAIL PROTECTED]> wrote: > mkdir test_make test_make/a test_make/b test_make/a/aa test_make/a/ab > touch test_make/a/ab/foo.c test_make/b/bar.c ... > %.c: ../ab/%.c > cp $< $@ ... > So that, bar.c gets copied to the Makefile directory, while foo.c does not.
Right. Let's look at the error message: make: stat: ../ab/../ab/../ab/../ab/../<elided>/ab/../ab/../ab/foo.c: File name too long You told make to build foo.c; the pattern rule that matched said it had "../ab/foo.c" as a prerequisite. So make now checks to see if it can build "../ab/foo.c" and finds a matching pattern rule: that same rule! It matches with the '%' being "../ab/foo", so the matching prerequisite is "../ab/../ab/foo.c" and it continues to loop. So, the problem is that the pattern rules results in a prerequisite that matches the same rule again *and* refers to the same file. The other pattern rule doesn't have that problem with 'bar.c' because the prerequisite is at a different directory level, so when the rule tries to match again it fails because the prereq doesn't exist. The first consideration in solving this is whether you can remove these rules and instead just use the VPATH variable or the vpath directive. You should read chapter 4.5 "Searching Directories for Prerequisites" in the info pages for the details. That's probably the simplest and cleanest way to solve this. If there's some insurmountable blocker to using VPATH or vpath, then I would consider changing the pattern rules to have two colons. This makes them 'terminal' rules, so that make will only apply them if the prerequisite file exists and make won't try to build that prerequisite file from something else. If the source files (../ab/foo.c and ../../b/bar.c) need to themselves be built as part of the run, then this won't work. Philip Guenther _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
