make - Support: sr #106077, Make decides that it built an...
You are not allowed to post comments on this tracker with your current authentication level.
sr #106077: Make decides that it built an object file, but didn't actually do it.
Submitter: | Clay Harris <cosmos> | ||
Submitted: | Wed 07 Nov 2007 08:18:01 PM UTC | ||
Category: | None | Priority: | 5 - Normal |
Severity: | 3 - Normal | Status: | None |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open | Operating System: | POSIX-Based |
Attached Files
file #14335: makefile added by cosmos (1KiB - application/octet-stream - Make 3.81 test (using gcc))
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follows 1 latest change.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2007-11-07 | cosmos | Attached File | - | ![]() |
Added makefile, #14335 |
The attached makefile demonstrates the problem.
I think the following discussion may be related.
Make manual section 10.5.4 (How patterns match)
is ambiguous on which "directory names" are reattached
to a prerequisite after a rule is selected.
Given:
%.o %.d: %.c
<tab> $(COMPILE.c) ... generate .o and .d
../c1.o ../c1.d: src/c1.c
c1 should match the pattern rule above.
The question is which directory name is reattached, I.e.
the one from the target or the one specified with the prereq.
../c1.o ../c1.d: ../c1.c
OR
../c1.o ../c1.d: src/c1.c
If a prereq has a directory specified, we would always
want to use it in preference to the directory of the target.
Is this what make does?