On Thu, 2017-06-15 at 17:18 +0200, SF Markus Elfring wrote: > define rule_pair = > name::=$(1) > $$(name:.ml=.cmo): $$(name) > $$(OCAMLC_CMD) -c $$< > > $$(name:.ml=.cmx): $$(name) > $$(OCAMLOPT_CMD) -c $$< > endef > > $(foreach x,$(SRC_without_mli),$(eval $(call rule_pair,$(x))))
What Philip is saying (and I agree 100%) is that you provide the above example which is excellent and helpful and allows us to see exactly what you're doing. Thank you for that. But then, you ask questions which are abstract and require a lot of effort on our part to understand. We all have a lot of demands on our time so the less effort we need to make to help someone, the more likely that help is to be offered. For example: > 2. The specification “$$(name)” is working. Would it make sense to avoid > such a variable reference there? > Unfortunately, the simple specification “$(1)” does not work in the way > I would expect for the selection of a single file as a dependency. > Would you like to explain this software behaviour? This seems to say that when you tried to use something different than the $$(name) reference above, it didn't work the way you expected. However, you provide no information on what the "something different" that you tried was, how it worked, or how you expected it to work. In programming (and makefiles) everything is about the details. The statement "I would expect for the selection of a single file as a dependency" is, at best, hard to understand (personally I didn't understand it). Instead of this abstract paragraph, why don't you _SHOW_ the change that you made, by repeating the above example with the change you tried, then _showing_ the result you got, and stating specifically exactly what you wanted to get instead? We can't deal with a 200-line makefile embedded in a question, but a few 10-15 line example makefiles along with specific example output and details on what was expected are much easier for us to understand and comment on than a written description that requires us to make a lot of guesses about what you're actually doing. Cheers! _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
