On Thu, 15 Jun 2017, SF Markus Elfring wrote: > I have constructed the following small script to be executed by the program > “GNU Make 4.2.1-1.7” on my openSUSE Tumbleweed system. > > > define rule_pair = > name::=$(1)
Using ::= in a makefile which is already dependent on GNU make is, IMO, pointless. If you're using $(eval) and $(call) then you should rename this file to GNUmakefile and just use := because it's portable across practically all versions of GNU make. It's free to you annd it'll make developers on non-Linux systems more happy since you'll have signalled the GNU make requirement directly. > $$(name:.ml=.cmo): $$(name) > $$(OCAMLC_CMD) -c $$< > > $$(name:.ml=.cmx): $$(name) > $$(OCAMLOPT_CMD) -c $$< > endef > > $(foreach x,$(SRC_without_mli),$(eval $(call rule_pair,$(x)))) > > > I guess that the functionality from this approach is similar to the > usage of two specific suffix rules. But I would like to distinguish the > involved software dependencies better. > > > I imagine that it would be nice to improve the shown implementation > details. > > 1. I am using the extra variable “name” just for the reuse of the make > functionality “substitution references”. You can substitution references with ${1} directly, ala ${1:.ml=.cmo} > I would prefer to append desired file name suffixes directly instead > of replacing a previous one. Can the passed text list become a bit > smaller eventually? I *think* you're asking whether rule_pair could take just the bare basename (ala "commands" instead of "commands.ml"). If so, then sure: a substitution reference could have an empty replacement part: ${1:=.cmo} will expand to "commands.cmo" if $1 is "commands" > 2. The specification “$$(name)” is working. Would it make sense to avoid > such a variable reference there? Unfortunately, the simple > specification “$(1)” does not work in the way I would expect for the > selection of a single file as a dependency. Would you like to explain > this software behaviour? I started to write a long explanation of how $(eval) works but then realized it didn't explain when $(1) didn't work for you. So: nope, can't explain the error message you saw, because it makes *no sense* to me why it didn't work based on what you wrote. In case the theme of my replies isn't 100% clear: it would be a *lot* easier to assist you if you included the complete input you tried, the complete output you got, and *what you expected/desired*. Or we can guess, and then give up and go away. Philip _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make