>> 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 _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
