bug-make
[Top][All Lists]
Advanced

[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 10:28:05 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0

> Using ::= in a makefile which is already dependent on GNU make is, IMO, 
> pointless.

I am trying to use portable make specifications to some degree.
But it seems to be challenging to avoid the usage of all the nice
functionality which is provided as extensions also by this software
development tool.


> You can substitution references with ${1} directly, ala ${1:.ml=.cmo}

Thanks for this advice.


> I *think* you're asking whether rule_pair could take just the bare 
> basename (ala "commands" instead of "commands.ml").

Your view is appropriate.


> If so, then sure: a substitution reference could have an empty replacement 
> part:
>       ${1:=.cmo}
> 
> will expand to "commands.cmo" if $1 is "commands"

I was not used to this possibility.

* Would it make sense to extend any documentation for such an use case?

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


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

Interesting …


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

Does this kind of feedback mean also that there are specific details
worth for further clarifications?


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

I fiddle with bigger make scripts once more where I try to exclude
some code at the beginning of another clarification attempt.

I would like to avoid efforts for a dedicated test script (for a moment).


> Or we can guess,

This can happen.


> and then give up and go away.

This is another usual possibility.

But I find your constructive feedback very promising and helpful.
I am curious on how such a dialogue will be continued.

Regards,
Markus



reply via email to

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