[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Evaluating a variable only once after a recipe has run
From: |
R. Diez |
Subject: |
Re: Evaluating a variable only once after a recipe has run |
Date: |
Sun, 19 Apr 2020 11:20:07 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 |
> Oh. Well, you should just ask :)
Many thanks, you are a star. ;-)
> [...]
> Deferred = $1 = $$(eval $1 := $$$$(shell $2))$$($1)
Is there a way to allow variable number of arguments? This is so that all of
the following work:
$(eval $(call Deferred,OUTPUT,some-command))
$(eval $(call Deferred,OUTPUT,some-command arg1))
$(eval $(call Deferred,OUTPUT,some-command arg1 arg2))
I could not see in the GNU Make documentation an indication about what happens
if the function uses 2 arguments and you pass 3.
I have yet another question: why is $(eval $(call ...)) necessary? Is it not
possible to write it so that the user only needs a $(call ) ?
> There are issues with this. If the command you want to run has
> unmatched ")" you have problems.
I am guessing that escaping a ')' is not possible. But I can live with:
CLOSING_PARENTHESIS := )
$(eval $(call Deferred,OUTPUT,some-command $(CLOSING_PARENTHESIS)))
Or will the nested $(eval) invocations break the usual trick with
CLOSING_PARENTHESIS ?
> Also if you want use a literal
>'$' in some-command you'll have problems getting enough
> escaping although it can be done.
You mean that $$ is not enough in this example?
$(eval $(call Deferred,OUTPUT,some-command arg1 $$ arg2))
> Personally I'm not convinced the eval/call version is more
> readable but YMMV.
I believe that this is important. You have written "Whoa! What is going on here?" in your blog. I would like to avoid that very effect every time
somebody sees the trick inside a makefile. Having a function with an informative name avoids most questions. If there are any left, the function is
the single point where you can find all documentation and warnings about itr.
I would like to put together in the comments of that function a few examples of how to use it, what pitfalls there are with escaping, and yet more
examples about how to work-around those escaping pitfalls. Or maybe with examples of what is not possible. Then I would have a function that you can
use 95 % of the time without having to think too much about it.
Thanks again,
rdiez
- Evaluating a variable only once after a recipe has run, R. Diez, 2020/04/18
- Re: Evaluating a variable only once after a recipe has run, Kaz Kylheku (gmake), 2020/04/18
- Re: Evaluating a variable only once after a recipe has run, R. Diez, 2020/04/18
- Re: Evaluating a variable only once after a recipe has run, Kaz Kylheku (gmake), 2020/04/18
- Re: Evaluating a variable only once after a recipe has run, R. Diez, 2020/04/18
- Re: Evaluating a variable only once after a recipe has run, R. Diez, 2020/04/18
- Re: Evaluating a variable only once after a recipe has run, Paul Smith, 2020/04/18
- Re: Evaluating a variable only once after a recipe has run, R. Diez, 2020/04/18
- Re: Evaluating a variable only once after a recipe has run, Paul Smith, 2020/04/18
Re: Evaluating a variable only once after a recipe has run, Paul Smith, 2020/04/18
- Re: Evaluating a variable only once after a recipe has run,
R. Diez <=