Compacting link-rules

[Gisle Vanem]

Hello list.

I need help with compacting a series of rules like (from a
Qwt makefile):

animation_OBJ = examples/animation/main.obj \
examples/animation/plot.obj

barchart_OBJ = examples/barchart/barchart.obj \
examples/barchart/main.obj \
examples/barchart/moc_barchart.obj

bin/animation.exe: $(animation_OBJ) $(LIBS)
$(call link_EXE, $@, $^)

bin/barchart.exe: $(barchart_OBJ) $(LIBS)
$(call link_EXE, $@, $^)

... plus a lot more

into a more compact rule like:
bin/%.exe: $($(@F)_OBJ) $(LIBS)
$(call link_EXE, $@, $^)

But I fail to get a correct param-2 for my link_EXE macro.
What would be the correct syntax for this? (if at all possible).

This is for MSVC/clang-cl. I'm on Windows-10 using GNU-make v 4.2.90.

--
--gv

[Paul Smith]

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

[Gisle Vanem]

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

[Paul Smith]

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.

[Gisle Vanem]

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

[Edward Welbourne]

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.

[Paul Smith]

On Fri, 2018-10-19 at 09:39 +0000, 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.

[Eddy Petrișor]

joi, 18 oct. 2018, 18:56 Paul Smith <***@gnu.org> 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

[Paul Smith]

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!

[Eddy Petrișor]

Will do.

Eddy

vin., 19 oct. 2018, 16:52 Paul Smith <***@gnu.org> 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!
>
>