[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Checking alternatives for a dynamic make rule construction

From: SF Markus Elfring
Subject: Re: Checking alternatives for a dynamic make rule construction
Date: Sat, 17 Jun 2017 21:45:37 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0

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

In how many source files should corresponding information be integrated
to make these special cases better known for substitution references?

> 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.

* Will another link help between documentation sections?

* Can a shorthand become relevant for such a function?

>> 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.

I imagine that the mentioned function call variants have got a different
impact on the run time behaviour.
How often do you stumble on the need to improve software build performance?

>> 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.

Would it make sense to configure aliases only from within (longer)
function implementations?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]