[bug #29814] Library search feature should be configurable for multilib systems
Follow-up Comment #2, bug #29814 (project make): Make will use VPATH (or vpath) for library search as well. So, on a multilib system, you can add: vpath lib% /...whatever... to specify where to look for libraries, for example. ___ Reply to this item at: http://savannah.gnu.org/bugs/?29814 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 item at: http://savannah.gnu.org/bugs/?29665 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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: http://savannah.gnu.org/bugs/?28983 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 wants to build a program for a secondary architecture could even set LIBDIRNAME (along with CFLAGS) on the command line to use the appropriate search directories. ___ Reply to this item at: http://savannah.gnu.org/bugs/?29814 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #28983] forcing a target matching a pattern rule shadows the rule's actions
Follow-up Comment #4, bug #28983 (project make): The GNU make manual both supports and defeats Matt's statement. A phony target is one that is not really the name of a file. [..] Once this is done, `make clean' will run the commands regardless of whether there is a file named clean. It would be a nuisance for the builds of pre-requisites of .PHONY to depend on existence of the files by the same name. Introducing an intermediate dependency can only reduce but not completely eliminate the possibility of a name clash. ___ Reply to this item at: http://savannah.gnu.org/bugs/?28983 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 that marking a target phony is a general way to force it to be rebuilt, you're wrong. I don't understand your objection to the FORCE idiom either. Here is your makefile rewritten to use FORCE: default: file.o FORCE: .PHONY: FORCE file.o: FORCE file.c: echo Auto-generating $@... touch $@ %.o: %.c echo Making $@ from $^... touch $@ The only pre-requisite of .PHONY (let's just call it a phony target) is FORCE itself, and the purpose of marking it phony is to _not_ be affected by a file of the that name, though such a file should never exist anyway. What is the potential name clash you mention? ___ Reply to this item at: http://savannah.gnu.org/bugs/?28983 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #28983] forcing a target matching a pattern rule shadows the rule's actions
Follow-up Comment #6, bug #28983 (project make): The following tests show that .PHONY's pre-requisites are normally rebuilt regardless of existence of a file with the same name. This works, $ cat test-force.mak default: file.o .PHONY: file.o file.o: echo Building $...@... $@ $ make -f test-force.mak echo Building file.o... file.o $ ls -al file.o -rw-r--r-- 1 ilatypov Domain Users 19 May 7 19:58 file.o $ rm file.o $ make -f test-force.mak echo Building file.o... file.o $ ls -al file.o -rw-r--r-- 1 ilatypov Domain Users 19 May 7 19:58 file.o $ make -f test-force.mak echo Building file.o... file.o +verbatim- And this works, $ cat test-force2.mak default: file.o .PHONY: file.o file.c: echo Auto-generating $...@... $@ file.o: file.c @echo Building $@ from $^... cat $^ $@ $ rm file.c file.o $ make -f test-force2.mak echo Auto-generating file.c... file.c Building file.o from file.c... cat file.c file.o $ make -f test-force2.mak Building file.o from file.c... cat file.c file.o $ make -f test-force2.mak Building file.o from file.c... cat file.c file.o $ rm file.o $ make -f test-force2.mak Building file.o from file.c... cat file.c file.o +verbatim- But this does not, $ cat test-force3.mak default: file.o .PHONY: file.o file.c: echo Auto-generating $...@... $@ %.o: %.c @echo Building $@ from $^... cat $^ $@ $ rm -f file.c file.o $ make -f test-force3.mak make: Nothing to be done for `default'. +verbatim- This allows me to think that my expectation in the original bug report was valid. And a pattern rule should not be affected by the phoniness of a target. ___ Reply to this item at: http://savannah.gnu.org/bugs/?28983 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #28983] forcing a target matching a pattern rule shadows the rule's actions
Follow-up Comment #7, bug #28983 (project make): The following tests show that .PHONY's pre-requisites are normally rebuilt regardless of existence of a file with the same name. This works, $ cat test-force.mak default: file.o .PHONY: file.o file.o: echo Building $...@... $@ $ make -f test-force.mak echo Building file.o... file.o $ ls -al file.o -rw-r--r-- 1 ilatypov Domain Users 19 May 7 19:58 file.o $ rm file.o $ make -f test-force.mak echo Building file.o... file.o $ ls -al file.o -rw-r--r-- 1 ilatypov Domain Users 19 May 7 19:58 file.o $ make -f test-force.mak echo Building file.o... file.o And this works, $ cat test-force2.mak default: file.o .PHONY: file.o file.c: echo Auto-generating $...@... $@ file.o: file.c @echo Building $@ from $^... cat $^ $@ $ rm file.c file.o $ make -f test-force2.mak echo Auto-generating file.c... file.c Building file.o from file.c... cat file.c file.o $ make -f test-force2.mak Building file.o from file.c... cat file.c file.o $ make -f test-force2.mak Building file.o from file.c... cat file.c file.o $ rm file.o $ make -f test-force2.mak Building file.o from file.c... cat file.c file.o But this does not, $ cat test-force3.mak default: file.o .PHONY: file.o file.c: echo Auto-generating $...@... $@ %.o: %.c @echo Building $@ from $^... cat $^ $@ $ rm -f file.c file.o $ make -f test-force3.mak make: Nothing to be done for `default'. This allows me to think that my expectation in the original bug report was valid. And a pattern rule should not be affected by the phoniness of a target. ___ Reply to this item at: http://savannah.gnu.org/bugs/?28983 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
