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 - NormalItem Group: Enhancement
Status: NonePrivacy: Public
Assigned to: NoneOpen/Closed: Open
Component Version: NoneOperating System: Any
Fixed Release: NoneTriage Status: Medium Effort

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

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

 

(Jump to the original submission 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)))

#
qib_compiler_generate_object_rules=\
$(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)

endef

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

http://stackoverflow.com/questions/2880975/make-invoke-command-for-multiple-targets-of-multiple-files

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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

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

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 09 Jul 2010 09:33:14 PM UTCpsmithTriage StatusNone=>Medium Effort
    Tue 06 Jul 2010 03:30:32 PM UTCr_pCarbon-Copy-=>Added r_p
    Tue 06 Jul 2010 03:22:58 PM UTCr_pCarbon-Copy-=>Added -unavailable-

    Back to the top


    Powered by Savane 3.1-cleanup