[bug #19975] Add function: $(mtime foo.c) -> 1180203683

URL: Summary: Add function: $(mtime foo.c) -> 1180203683 Project: make Submitted by: hashproduct Submitted on: Saturday 05/26/2007 at 18:39 Severity: 3 - Normal Item Gro

[bug #19975] Add function: $(mtime foo.c) -> 1180203683

Additional Item Attachment, bug #19975 (project make): File name: make-func-mtime.diff Size:1 KB ___ Reply to this item at: ___ Message sent

[bug #19975] Add function: $(mtime foo.c) -> 1180203683

Follow-up Comment #3, bug #19975 (project make): That's wonderful news. I'll work on the other parts of the tool for now and revisit the out-of-date criterion once I see the results of the Summer of Code project. ___ Reply to this item at

[bug #20501] "MAKEFLAGS += -rR" doesn't turn off default suffix rules, variables

URL: Summary: "MAKEFLAGS += -rR" doesn't turn off default suffix rules, variables Project: make Submitted by: hashproduct Submitted on: Tuesday 07/17/2007 at 03:58 Severity: 3 - Norma

[bug #20502] Allow attaching target-specific variables to implicit rules

URL: Summary: Allow attaching target-specific variables to implicit rules Project: make Submitted by: hashproduct Submitted on: Tuesday 07/17/2007 at 05:03 Severity: 3 - Normal

Re: Switching from CVS to GIT

On 10/13/07, Paul Smith <[EMAIL PROTECTED]> wrote: > It seems like GIT is where the mindshare is these days, plus a number of > the other autotools projects have already migrated (or are in the middle > of migrating) to GIT, so that's what I'd go with. > please give me your opinions on this change

[bug #20501] "MAKEFLAGS += -rR" doesn't turn off default suffix rules, variables

Follow-up Comment #5, bug #20501 (project make): Note the following comments emailed to the bug-make list: http://lists.gnu.org/archive/html/bug-make/2008-01/msg00020.html http://lists.gnu.org/archive/html/bug-make/2008-01/msg00021.html Philip, you are right that there is no clean, general way

[bug #29620] Implicit rule search is still sensitive to random side effects

URL: Summary: Implicit rule search is still sensitive to random side effects Project: make Submitted by: hashproduct Submitted on: Tue 20 Apr 2010 04:14:59 PM EDT Severity: 3 - Normal

[bug #29814] Library search feature should be configurable for multilib systems

Follow-up Comment #1, bug #29814 (project make): This was me, forgetting to log in. Sorry. ___ Reply to this item at: ___ Message sent via/by Savannah

[bug #29665] .PHONY included makefiles are rebuilt but not reread

Follow-up Comment #1, bug #29665 (project make): Since the makefile is a real file, you shouldn't be marking it phony. The usual way to force a target to always be remade is to have it depend on a phony target "FORCE". ___ Reply to this i

[bug #28983] forcing a target matching a pattern rule shadows the rule's actions

Follow-up Comment #3, bug #28983 (project make): The technique in comment #1 is actually the recommended solution, with the dummy target named FORCE. Phoniness is only for targets that are not files. ___ Reply to this item at:

[bug #29814] Library search feature should be configurable for multilib systems

Follow-up Comment #3, bug #29814 (project make): That requires changes to every makefile. With my proposed patch series, distributions that want to support multilib would be able to configure "make" to use the correct standard search directories for the system's primary architecture. A user who

[bug #28983] forcing a target matching a pattern rule shadows the rule's actions

Follow-up Comment #5, bug #28983 (project make): I don't understand how the second quote defeats my statement. The point is that marking the "clean" target phony prevents the accidental existence of a file by that name from confusing the build system. If you're trying to argue from that quote t