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

 
 

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

Submitter:  Reinier Post <r_p>
Submitted:  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
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group 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>
Group administrator
Fri 09 Jul 2010 08:29:48 PM UTC, comment #2: 
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.



progs = dot neato circo fdp
exts = emf ps png gif

%-$(p:progs).$(x:exts): %.dot
  $(p) -T%(x) $? > $@


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:
   
   
Comment:
   

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
  •  

    There are 80 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    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.13-f8d8.
    Corresponding source code