Re: Compacting link-rules
Will do. Eddy vin., 19 oct. 2018, 16:52 Paul Smith a scris: > On Fri, 2018-10-19 at 09:26 +0300, Eddy Petrișor wrote: > > I have a similar issue, but in my case I used explicit pattern rules, > > vpath and added compiler generated .d files to make sure the object > > files are regenerated on .h modification, but the end result was that > > the pattern rules were no longer called after the initial generation. > > > > My tentative explanation is that the .d dependency rules are > > considered more specific (but empty) than the pattern rules and/or > > vpath is at fault, also. > > > > Is this explanation correct? Will the issue also appear in the > > solution above? > > I'm sorry but I don't understand your description. If you would like > some help please post a minimal, complete example (and create a new > mailing list thread for it). Cheers! > > ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Compacting link-rules
On Fri, 2018-10-19 at 09:26 +0300, Eddy Petrișor wrote: > I have a similar issue, but in my case I used explicit pattern rules, > vpath and added compiler generated .d files to make sure the object > files are regenerated on .h modification, but the end result was that > the pattern rules were no longer called after the initial generation. > > My tentative explanation is that the .d dependency rules are > considered more specific (but empty) than the pattern rules and/or > vpath is at fault, also. > > Is this explanation correct? Will the issue also appear in the > solution above? I'm sorry but I don't understand your description. If you would like some help please post a minimal, complete example (and create a new mailing list thread for it). Cheers! ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Compacting link-rules
On Fri, 2018-10-19 at 09:39 +, Edward Welbourne wrote: > TARGETS = bin/animation.exe bin/barchart.exe ... > > $(TARGETS): bin/%.exe: $(%_OBJ) $(LIBS) > $(call link_EXE, $@, $^) If you try this, you'll see it doesn't work. Variables are expanded before the pattern is substituted, so $(%_OBJ) tries to expand the variable %_OBJ which is empty. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Compacting link-rules
Paul Smith wrote: >>> All the .obj files are missing!? >> >> Oh. $@ is "bin/animation.exe" so $(@F) is "animation.exe" and >> $($(@F)_OBJ) would be "animation.exe_OBJ" but that's not the name of >> your variable, so it expands to the empty string. >> >> Sorry I didn't catch this problem in your original suggestion. >> >> You want: >> >>bin/%.exe: $$($$*_OBJ) $(LIBS) >>... >> >> because $* matches the pattern stem, which is "animation" in this case. Gisle Vanem (18 October 2018 19:40) replied: > That seems to work fine. Thanks a lot! Good to hear. For completeness's sake, note another approach that might work: TARGETS = bin/animation.exe bin/barchart.exe ... $(TARGETS): bin/%.exe: $(%_OBJ) $(LIBS) $(call link_EXE, $@, $^) using the other kind of pattern rule, Eddy. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Compacting link-rules
joi, 18 oct. 2018, 18:56 Paul Smith a scris: > On Thu, 2018-10-18 at 17:40 +0200, Gisle Vanem wrote: > >bin/%.exe: $($(@F)_OBJ) $(LIBS) > >$(call link_EXE, $@, $^) > > This cannot work because automatic variables like $@, etc. are only > valid _inside a recipe_. They are not set and cannot be used in target > or prerequisite lists: they expand to the empty string. > > You have two choices. You can either separate the prerequisites from > the recipe, like this: > > bin/%.exe: > $(call link_EXE,$@,$^) > > bin/animation.exe: $(animation_OBJ) $(LIBS) > bin/barchart.exe: $(barchart_OBJ) $(LIBS) > I have a similar issue, but in my case I used explicit pattern rules, vpath and added compiler generated .d files to make sure the object files are regenerated on .h modification, but the end result was that the pattern rules were no longer called after the initial generation. My tentative explanation is that the .d dependency rules are considered more specific (but empty) than the pattern rules and/or vpath is at fault, also. Is this explanation correct? Will the issue also appear in the solution above? Or, you can enable secondary expansion which will allow you to write: > > .SECONDEXPANSION: > > bin/%.exe: $$($$(@F)_OBJ) $(LIBS) > $(call link_EXE, $@, $^) > > (note the extra "$" in the variable references. See: > > https://www.gnu.org/software/make/manual/make.html#Secondary-Expansion > Eddy ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Compacting link-rules
Paul Smith wrote: All the .obj files are missing!? Oh. $@ is "bin/animation.exe" so $(@F) is "animation.exe" and $($(@F)_OBJ) would be "animation.exe_OBJ" but that's not the name of your variable, so it expands to the empty string. Sorry I didn't catch this problem in your original suggestion. You want: bin/%.exe: $$($$*_OBJ) $(LIBS) ... because $* matches the pattern stem, which is "animation" in this case. That seems to work fine. Thanks a lot! -- --gv ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Compacting link-rules
On Thu, 2018-10-18 at 18:32 +0200, Gisle Vanem wrote: > > .SECONDEXPANSION: > > bin/%.exe: $$($$(@F)_OBJ) $(LIBS) > $(call link_EXE, $@, $^) > > Very compact and nice. But trying it, it wont work. > For 'bin/animation.exe', it expands to: > bin/animation.exe: $(LIBS) > link -nologo -debug -incremental:no -map -subsystem:windows > -out:bin/controls.exe lib/Qwt.lib ... > > All the .obj files are missing!? Oh. $@ is "bin/animation.exe" so $(@F) is "animation.exe" and $($(@F)_OBJ) would be "animation.exe_OBJ" but that's not the name of your variable, so it expands to the empty string. Sorry I didn't catch this problem in your original suggestion. You want: bin/%.exe: $$($$*_OBJ) $(LIBS) ... because $* matches the pattern stem, which is "animation" in this case. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Compacting link-rules
Paul Smith wrote: Or, you can enable secondary expansion which will allow you to write: .SECONDEXPANSION: bin/%.exe: $$($$(@F)_OBJ) $(LIBS) $(call link_EXE, $@, $^) Very compact and nice. But trying it, it wont work. For 'bin/animation.exe', it expands to: bin/animation.exe: $(LIBS) link -nologo -debug -incremental:no -map -subsystem:windows -out:bin/controls.exe lib/Qwt.lib ... All the .obj files are missing!? Trying a: .SECONDEXPANSION: $(animation_OBJ) does not make a difference. Also a 'make -p' show: bin/animation.exe: lib/Qwt.lib and nothing else. Qwt.lib is part of $(LIBS). -- --gv ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Compacting link-rules
On Thu, 2018-10-18 at 17:40 +0200, Gisle Vanem wrote: >bin/%.exe: $($(@F)_OBJ) $(LIBS) >$(call link_EXE, $@, $^) This cannot work because automatic variables like $@, etc. are only valid _inside a recipe_. They are not set and cannot be used in target or prerequisite lists: they expand to the empty string. You have two choices. You can either separate the prerequisites from the recipe, like this: bin/%.exe: $(call link_EXE,$@,$^) bin/animation.exe: $(animation_OBJ) $(LIBS) bin/barchart.exe: $(barchart_OBJ) $(LIBS) Or, you can enable secondary expansion which will allow you to write: .SECONDEXPANSION: bin/%.exe: $$($$(@F)_OBJ) $(LIBS) $(call link_EXE, $@, $^) (note the extra "$" in the variable references. See: https://www.gnu.org/software/make/manual/make.html#Secondary-Expansion ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
