Re: Checking alternatives for a dynamic make rule construction

[Philip Guenther]

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