[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
- Checking alternatives for a dynamic make rule construction, SF Markus Elfring, 2017/06/15
- Re: Checking alternatives for a dynamic make rule construction, Philip Guenther, 2017/06/17
- Re: Checking alternatives for a dynamic make rule construction,
SF Markus Elfring <=
- Re: Checking alternatives for a dynamic make rule construction, Paul Smith, 2017/06/17
- Re: Checking alternatives for a dynamic make rule construction, SF Markus Elfring, 2017/06/17
- Re: Checking alternatives for a dynamic make rule construction, Paul Smith, 2017/06/17
- Re: Checking alternatives for a dynamic make rule construction, SF Markus Elfring, 2017/06/17
- Re: Checking alternatives for a dynamic make rule construction, Paul Smith, 2017/06/17
- Re: Checking alternatives for a dynamic make rule construction, SF Markus Elfring, 2017/06/17
- Re: Checking alternatives for a dynamic make rule construction, Paul Smith, 2017/06/17
- Re: Checking alternatives for a dynamic make rule construction, SF Markus Elfring, 2017/06/17