Re: Checking alternatives for a dynamic make rule construction

[Paul Smith]

On Sat, 2017-06-17 at 20:21 +0200, SF Markus Elfring wrote:
> > > my_test_command?=cat
> > > 
> > > define my_rule_demo=
> > > name::=${1}
> > > $${name:.in=.txt}: ${1}
> > >         $${my_test_command} $$< > $$@
> > > endef
> > > 
> > > $(eval $(call my_rule_demo,MOTD.in))
> > 
> > Is there something wrong with it?
> I sent it just as another follow-up in the hope to reduce a few
> of our communication difficulties.
> Can such tiny code examples help in this dialogue at all?

Certainly they are very helpful, but only when combined with an explicit
question or request.  If you include a makefile with no discussion of
what about it concerns you enough to send it to the mailing list, we
don't know what to do with it.

> > > How would you like to clarify remaining details from other requests?
> > 
> > I'm sorry but I've lost track of what issues have been resolved versus
> > which are still outstanding.  If you can provide an example and a
> > specific question, we can attempt to respond.
> 
> I hope that there will no confusion occur with subjects from
> my other recent discussion threads.
> I am still curious about information I presented at 10:28.
> http://lists.gnu.org/archive/html/bug-make/2017-06/msg00093.html
> 
> Repetition:
> 1. Will it make sense to extend any documentation for “substitution
> references”?

Sure, it could be made clear in the documentation that either of the
sides of the "=" could be empty.

However, there are plenty of ways to do this same thing:

In your situation where there's only one word in the ${1} variable,
"${1:=.cmo}" is the same as writing "${1}.cmo" which is even simpler and
easier to understand.

In a situation where there may be multiple words in the variable that
you want to modify, you can consider using the "$(addsuffix .cmo,${1})"
function which is arguably more clear than using substitution references
and does the same thing as using an empty left-hand side value.

> 2. Can the distinction between appending suffixes and replacing them become
>    occasionally more relevant for better software build characteristics?

I don't know how to respond to this.

> Another software extension:
> How are the chances to assign aliases to numbered temporary variables?

At this time I don't see the need to add such a thing.  At the moment I
don't see a reasonable way to extend the existing "call" syntax to
provide aliases.