LTC Owner is: gilliam.com LTC Originator is: lagarcia.com Problem description: According to section 4.7 of make info manual (`info make' -> Rules:: -> Force Targets::) we can use a FORCE target to force the execution of a rule. This should work similar to the use of a .PHONY target. However, according to bug #12331 (http://savannah.gnu.org/bugs/?12331) there was a conflict if we use a .PHONY target with a .SECONDARY target without prerequisites. This problem didn't exist in make 3.80 and it was fixed for make 3.81 release. However, according to my tests, there is a similar problem if we use a FORCE target with a .SECONDARY target without prerequisites. This problem didn't occur in make 3.80 and started to occur with make 3.81. I am using make 3.81 that comes with Fedora Core 6 in package make-3.81-1.1. If this is not an installation problem, Describe any custom patches installed. No patches. Provide output from "uname -a", if possible: Linux lagarcia.br.ibm.com 2.6.19-1.2895.fc6 #1 SMP Wed Jan 10 19:28:18 EST 2007 i686 i686 i386 GNU/Linux Hardware Environment Machine type (p650, x235, SF2, etc.): ThinkPad T42 Cpu type (Power4, Power5, IA-64, etc.): x86 Is this reproducible? Yes. If so, how long does it (did it) take to reproduce it? less than five minutes with the example files attaches. Describe the steps: - Download the attached files: in-file, makefile1.mk, makefile2.mk, makefile3.mk and makefile4.mk - Just run `make -f <file_name.mk>' to see what happens. +------------+--------+-------+------------+---------------+---------------+ | file name | .PHONY | FORCE | .SECONDARY | works on 3.80 | works on 3.81 | +------------+--------+-------+------------+---------------+---------------+ |makefile1.mk| yes | no | no | yes | yes | +------------+--------+-------+------------+---------------+---------------+ |makefile2.mk| yes | no | yes | yes | yes | +------------+--------+-------+------------+---------------+---------------+ |makefile3.mk| no | yes | no | yes | yes | +------------+--------+-------+------------+---------------+---------------+ |makefile4.mk| no | yes | yes | yes | NO | +------------+--------+-------+------------+---------------+---------------+ The problem solved by bug #12331 (http://savannah.gnu.org/bugs/?12331) is the case in makefile2.mk. Our problem is occurring with makefile4.mk. Is the system (not just the application) hung? No. Did the system produce an OOPS message on the console? No. Is the system sitting in a debugger right now? No. Created an attachment (id=24046) test file to run make tests Created an attachment (id=24047) make test #1 Created an attachment (id=24048) make test #2 Created an attachment (id=24049) make test #3 Created an attachment (id=24050) make test #4 Just wondering: Is this occurring in the makefile generated by the IDE or in building the IDE itself? Also, is there any workaround? Mirroring in progress...
Created attachment 146717 [details] in-file
Created attachment 146718 [details] makefile1.mk
Created attachment 146719 [details] makefile2.mk
Created attachment 146720 [details] makefile3.mk
Created attachment 146721 [details] makefile4.mk
------- Additional Comments From lagarcia.com 2007-01-29 10:22 EDT ------- (In reply to comment #7) > Just wondering: Is this occurring in the makefile generated by the IDE or in > building the IDE itself? Also, is there any workaround? Is this occurring in the makefile generated by the IDE or in building the IDE itself? It is occuring in the makefile generated by the IDE. Is there any workaround? No. Moving back to make 3.80 should work, however make 3.80 is not available in FC6.
Created attachment 148067 [details] makefile5.mk
----- Additional Comments From robbiew.com 2007-02-14 11:51 EDT ------- Workaround Makefile (makefile5.mk) This seems to be trivial for two reasons. 1) This only affects the "-f" flag, if the file is renamed to "Makefile" and a 'make' is ran...it works. 2) A simple workaround solution is to create an empty "nothing" section and refer to it in the .SECONDARY. (see attachment makefile5.mk)
Created attachment 148076 [details] makefile5.mk
------- Additional Comments From lagarcia.com (prefers email at lagarcia.ibm.com) 2007-02-14 12:55 EDT ------- (In reply to comment #15) > [edit] > Workaround Makefile (makefile5.mk) > > This seems to be trivial for two reasons. > 1) This only affects the "-f" flag, if the file is renamed to "Makefile" and a > 'make' is ran...it works. I tested this before opening the bug and tested it again now. For me, makefile4.mk, which has the problem described, doesn't work even if I rename to "Makefile" and run 'make'. > 2) A simple workaround solution is to create an empty "nothing" section and > refer to it in the .SECONDARY. (see attachment makefile5.mk) Unfortunately, this workaround doesn't suit for IDE. I also could use a .PHONY target instead of FORCE target (the result should be the same and .PHONY doesn't have the problem described). However, .PHONY and .SECONDARY targets are automatically generated by CDT. To change these, we will have to change CDT plug-ins or reimplement/copy hundreds of lines of code from CDT to change the way it generates the special targets.
.SECONDARY without dependencies will make all targets in makefile secondary. Secondary targets are treated as intermediate file, except not deleted afterwards. For intermediate files, make is free to omit their recreation, if none of the prerequisites changed. in-file didn't change for sure. We're left with FORCE, which is basically only a reference to non-existing *intermediate* file without dependencies. Documentation for .INTERMEDIATE states that intermediate file with no prerequisites has no effect, and I take this also applies to files declared as intermediate via .SECONDARY. This is not in contrast with your use of .PHONY. When out-file rule is marked .PHONY, the actions will be carried unconditionally. To my uderstanding, there is no bug. (In reply to comment #8) > ----- Additional Comments From robbiew.com 2007-02-14 11:51 EDT > > This seems to be trivial for two reasons. > 1) This only affects the "-f" flag, if the file is renamed to "Makefile" and a > 'make' is ran...it works. Works for me the same regardless of way the makefile is summoned. > 2) A simple workaround solution is to create an empty "nothing" section and > refer to it in the .SECONDARY. (see attachment makefile5.mk) That's because then the .SECONDARY target applies only to the "nothing" rule, not to all rules.
----- Additional Comments From lagarcia.com (prefers email at lagarcia.ibm.com) 2007-02-14 14:28 EDT ------- Ok. I understood what you said. However, from the 'info make' page, we have: File: make.info, Node: Force Targets, Next: Empty Targets, Prev: Phony Targets, Up: Rules 4.7 Rules without Commands or Prerequisites =========================================== If a rule has no prerequisites or commands, and the target of the rule is a nonexistent file, then `make' imagines this target to have been updated whenever its rule is run. This implies that all targets depending on this one will always have their commands run. An example will illustrate this: clean: FORCE rm $(objects) FORCE: Here the target `FORCE' satisfies the special conditions, so the target `clean' that depends on it is forced to run its commands. There is nothing special about the name `FORCE', but that is one name commonly used this way. As you can see, using `FORCE' this way has the same results as using `.PHONY: clean'. Using `.PHONY' is more explicit and more efficient. However, other versions of `make' do not support `.PHONY'; thus `FORCE' appears in many makefiles. *Note Phony Targets::. ----------------- According to what you described, this special condition with FORCE and .SECONDARY is a special case, right?
There are two special cases in effect: the special semantics of FORCE ("always updated"), and special semantics of immediate files ("no effect when no dependencies"). I didn't find it documented anywhere, but per current make implementation, the latter wins. The lack of description of this case might be considered a bug, but I don't think there is anything to be fixed on side of code. (In reply to comment #10) > Unfortunately, this workaround doesn't suit for IDE. I also could use a .PHONY > target instead of FORCE target (the result should be the same and .PHONY > doesn't have the problem described). However, .PHONY and .SECONDARY targets > are automatically generated by CDT. Well, it is possible to have several .PHONY targets in one file. E.g.: all: out-file out-file: in-file; cp in-file out-file clean:; rm -f out-file .PHONY: all clean .PHONY: out-file I don't know what exactly your IDE does, but if you have influence over what gets into the makefiles, you could add your own .PHONY to IDE's generated .PHONies.
----- Additional Comments From lagarcia.com (prefers email at lagarcia.ibm.com) 2007-02-15 16:28 EDT ------- Multiple .PHONY targets worked fine for me! I agree with the explanation about this not being a bug. For me, we can reject and close the bug.
Ok, closing.