bug-make
[Top][All Lists]
Advanced

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

Re: Difficulties from the combination of functions "call" and "eval"


From: SF Markus Elfring
Subject: Re: Difficulties from the combination of functions "call" and "eval"
Date: Sun, 18 Jan 2015 13:31:42 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

>> I have added another tab character to a multi-line variable definition
>> which should be called for a specific evaluation.
>> Now I get a bit of more "progress indication" from a different error message.
> 
> You're just trying random stuff and not paying attention!

I hope that I am becoming better over time here.


> Stop and *think*!

I'll try that of course.


> $(eval) takes as its argument a *CHUNK OF STANDALONE MAKEFILE*:
> a variable assignment, and rule w/ or w/o recipe, an export, a define,
> and if/endif block, etc.

I understood the available documentation in the way that the amount
of make source code which will be passed to the eval function can vary.


> NEITHER OF YOUR VARIABLES BELOW MEET THAT CRITERIA, SO PASSING THEIR
> EXPANSIONS TO $(eval) IS AN ERROR.

I find it interesting that you see my make file example in this way.



>> Lines 183 - 203:
>> define RESULT_CHECK
>>         for part in $(1); do \
>> if test "x$$(< $$part)" != "x0"; then \
>> $(PRINTF) "$$(TEXT3)" '$$part'; \
>> exit 12; \
>> fi; \
>> done \
>> && $$(TOUCH) '$(2)'
>> endef
> 
> That looks like it expands to shell text when used with $(call), so
> just call it in a recipe!

Yes. - The evaluated variable should produce shell commands for recipes.
I try to reuse it as a subfunction.


>> define HANDLE_BACKGROUND_TASK
>> @$(RM) '$(1)'
>>         $(file >$(2)) \
>> $(file >>$(2),for task in $$($(SEQ) $(PARALLEL_MAXIMUM) -1 0); \
>> do $(MAKE) -f $(3) -j1 index=$$task &; \
>> done) \
>> $(file >>$(2),wait)
>>         @cat '$(2)'
>>         $$SHELL '$(2)'
>>         $(eval $(call RESULT_CHECK,$(4),$(1)))
>> endef
> 
> Why are you using $(eval) there?

I try to generate a few statements which should be executed by recipes.


> Think: what does $(call RESULT_CHECK,$4,$1) expand to?

Will this make statement be expanded to a component for recipes?


> Would that expansion be a valid Makefile if you put it in its own file?

No. - I try to use this part for an other purpose.


> No?

Yes.


> It's just _part_ of a recipe?

It is a fragment for the reuse by another variable expansion.


> Then $(eval) is the Wrong Thing.

I hope not …


> Frankly, this entire HANDLE_BACKGROUND_TASK mess seems like it's at
> the wrong level.

I am curious to improve related implementation details.


> Either you should be letting the toplevel make handle the parallelism
> by expressing this all with targets and dependencies,

It is nice when it works on such an application programming interface.


> or push it to the shell level and just have each recipe start with
> a macro that expands to a canned block of shell that figures out
> whether its the first call and forks the background stuff then.

I guess that I am going to try more things out in this design direction.


> Or even wrap make in a shell script that does the imperative background
> stuff before starting make with a Makefile that doesn't have that insanity?

Other build targets use recursive makes in this way already.


> Make is itself a declarative language; forcing it into an imperative
> style is just going to give you ulcers, or more likely, give ulcers to
> your co-worker or co-maintainer or the six-months-from-now version of
> you, when they/you have to figure out how this Makefile works.

I hope that I will stay healthy with corresponding software development
challenges. I might get a few headaches on the way.

Regards,
Markus




reply via email to

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