bugmake - Bugs: bug #30370, add a shorthand syntax for...


bug #30370: add a shorthand syntax for foreach-eval-call

Submitted by:  Reinier Post <r_p>
Submitted on:  Tue 06 Jul 2010 03:22:58 PM UTC  
Votes:  80  
Severity:  3 - Normal Item Group:  Enhancement
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Component Version:  None Operating System:  Any
Fixed Release:  None Triage Status:  Medium Effort

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Mon 19 Jul 2010 10:09:52 AM UTC, comment #7:

Thanks for the comments.

Yes, supporting multiple masks directly in the dependency matching, based on regular expressions, is fundamentally different from using dynamically set variables as "pseudo-masks" which is what the foreach-call-eval-solution amounts to; if this is adopted, a special syntax to improve readability of the latter type of solution won't be necessary. (Olexiy, my makefiles look a little like yours. Surely you don't consider your example fragment as easy to read or write as a solution with multiple masks would be?)

Reinier Post <r_p>
Sat 17 Jul 2010 03:31:34 PM UTC, comment #6:

Interesting to findout which way will work faster. Many generated pattern rules? or PAttern rule with multiple masks

But in general I agree with Paul and Boris. Current make is flexible enough to generate common parts
Let me give you real life example of power of make

# build/ase/%.c => build/xlc/%.sc.o
$(eval $(call qib_compiler_generate_object_rules,c,$(qib_ase_tgt_dir),$(qib_ase_src_suffix)))

# %.cpp => build/xlc/%.cpp.o
$(eval $(call qib_compiler_generate_object_rules,cxx,,$(qib_cxx_src_suffix)))

# %.c => build/xlc/%.c.o
$(eval $(call qib_compiler_generate_object_rules,c,,$(qib_c_src_suffix)))

$(foreach qib_compiler_type_,$(qib_compiler_supported_types),\
$(foreach qib_compiler_variant_,$(qib_compiler_supported_variants),\
$(call qib_compiler_object_rule,$1,$2,$(QIB_DATABASE),$(qib_compiler_type_),$(qib_compiler_variant_),$3)\

# define gets 6 parameters!!!
define qib_compiler_object_rule

$$(qib_compiler_$4_dir)$5/%$6$$(qib_compiler_obj_suffix) : qib_real_source=$$(patsubst $$(qib_compiler_$4_dir)$5/%$$(qib_compiler_obj_suffix),%,$$(@))

$$(qib_compiler_$4_dir)$5/%$6$$(qib_compiler_obj_suffix) : $2%$$(qib_$1_src_suffix)
$$(call qib_debug_echo,$1,\
$$(if $$(qib_coverage_tgt_dir),$$(qib_posix_mkdir) $$(dir $$(@)) &&)\
$$(call qib_$1_$4_make,$$(@),$$(<),$5,$3)\

$$(qib_compiler_$4_dir)$5/%$6$$(qib_compiler_obj_suffix).out :: $$(qib_compiler_$4_dir)$5/%$6$$(qib_compiler_obj_suffix)


Olexiy Buyanskyy <olexiyb>
Sat 10 Jul 2010 10:40:15 AM UTC, comment #5:

I agree with Paul. The discussion on stackoverflow is talking about a more general mechanism, namely having pattern rules with multiple stems. I think if we were to consider such an extension, then it is better to go all the way and add support for regex-based patterns (which, BTW, are requested regularly by users).

What you are proposing is a convenient syntax to define a set of old-style pattern rules. The more general pattern rules will be able to handle your case but not vice-versa.

Boris Kolpackov <bosk>
Project Member
Fri 09 Jul 2010 10:05:35 PM UTC, comment #4:

The request at stackoverflow.com describes what I really want. I intentionally phrased the request in such a way that a particular implementation was suggested in order to avoid the criticism that the idea is "vague" or "infeasible".

The syntax would have to be clear, general, cand backward compatible at the same time. Hmmmm. Some extension to the $() syntax seems natural but I also like the idea of extending the % notation somehow.

Reinier Post <r_p>
Fri 09 Jul 2010 09:32:42 PM UTC, comment #3:

The major issue here, besides the effort involved of course, is finding a syntax or format that is backward compatible, at least enough to avoid breaking a lot of makefiles.

I also have to say that the request at stackoverflow.com and the request you make below are actually fundamentally different; it appears you are looking for a programmatic way to create large numbers of explicit rules, that is more flexible than existing static pattern rules.

The request at stackoverflow.com appears to be looking for a much more flexible method of defining pattern rules, where there can be multiple patterns in both the target and prerequisite lists.

Paul D. Smith <psmith>
Project Administrator
Fri 09 Jul 2010 08:29:48 PM UTC, comment #2:

An example is at


Reinier Post <r_p>
Tue 06 Jul 2010 03:32:10 PM UTC, comment #1:

-T%(x) should be -T$(x)

Reinier Post <r_p>
Tue 06 Jul 2010 03:22:58 PM UTC, original submission:

No bug, but something that has been on my wishlist for some 20 years:

In practically every Makefile I write, I want to parametrize rules with multiple variables. It would be incredibly nice to have a shorthand syntax for this, e.g.

instead of having to use ugly, verbose workarounds such as foreach-eval-call.

Reinier Post <r_p>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by olexiyb (Posted a comment)
  • -email is unavailable- added by bosk (Posted a comment)
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by r_p (Voted in favor of this item)
  • -email is unavailable- added by r_p (Submitted the item)
  • -email is unavailable- added by r_p

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 80 encouragements so far.

    Only logged-in users can vote.




    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-07-09 psmith Triage StatusNone => Medium Effort
    2010-07-06 r_p Carbon-Copy- => Added r_p
    2010-07-06 r_p Carbon-Copy- => Added -email is unavailable-

    Back to the top

    Powered by Savane 3.3