bugmake - Bugs: bug #51292, Handling make rules where...

 
 

bug #51292: Handling make rules where prerequisites are determined by functions for specific targets lists

Submitter:  Markus Elfring <elfring>
Submitted:  Thu 22 Jun 2017 01:10:13 PM UTC
   
 
Severity:  3 - Normal Item Group:  Enhancement
Status:  Wont Fix Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Component Version:  4.2.1 Operating System:  Any
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 02 Jul 2017 07:30:26 PM UTC, comment #8: 


> I dared to propose a software extension which can be similar to the functionality “static pattern rules”. Under which circumstances can the generic variant move into the standard functions?


I don't see any need to move something like this "into the standard functions".  If you want to be able to define a rule using a function syntax instead of a normal recipe syntax you can do this today with something like:


basic_rule = $1 : $2 ; $3

$(eval $(call basic_rule,target,prereq1 prereq2,recipe))


Paul D. Smith <psmith>
Group administrator
Sun 02 Jul 2017 05:18:15 PM UTC, comment #7: 


> If you want a "callback"-like setup you can already do it with eval and call:


This approach might be an approximation which can work as usual for a while.


> Personally I'm not convinced this is useful in general...


I dared to propose a software extension which can be similar to the functionality “static pattern rules”.
Under which circumstances can the generic variant move into the standard functions?


> But if you had one set of global makefiles that defined all the templates, etc. then used data-driven variable assignments to do the rest I suppose it might be useful.


Thanks that you can follow in this software design direction.

I imagine that make rule construction can become more dynamic.

Markus Elfring <elfring>
Sun 02 Jul 2017 05:05:29 PM UTC, comment #6: 

Was your feedback truncated by the tracking interface for this issue?

Markus Elfring <elfring>
Sun 02 Jul 2017 05:04:07 PM UTC, comment #5: 

Bleah, typo.  Rewriting:

You can easily add the suffix as part of the static pattern rule:


targets ::= foo bar

$(targets:=.o): %.o: %.c
        $(CC) -c $(CFLAGS) $< -o $@


If you want a "callback"-like setup you can already do it with eval and call:


# Function to generate a new rule.
# Call syntax: $(call new_rule,<target>,<callback_fn_name>)
define new_rule
$1 : $$(call $2,$1)
        $$(CC) -c $$(CFLAGS) $$< -o $$@
endef

# Example use
targets = foo bar biz

foo_prereq = foo1 foo2 foo3
bar_prereq = $(addsuffix .xx,$1)
biz_prereq = $(addprefix $1,.a .b .c)

$(foreach T,$(targets),$(eval $(call new_rule,$T,$T_prereq)))


You can of course also add other callbacks, for the target, recipe, etc.

Personally I'm not convinced this is useful in general... it's certainly a lot less readable (to me).  But if you had one set of global makefiles that defined all the templates, etc. then used data-driven variable assignments to do the rest I suppose it might be useful.

Paul D. Smith <psmith>
Group administrator
Sun 02 Jul 2017 05:00:13 PM UTC, comment #4: 

You can easily add the suffix as part of the static pattern rule:


targets ::= foo bar

$(targets:=.o): %.o: %.c
        $(CC) -c $(CFLAGS) $< -o $@
-vebatim-

If you want a "callback"-like setup you can already do it with eval and call:

+verbatim+
# Function to generate a new rule.
# Call syntax: $(call new_rule,<target>,<callback_fn_name>)
define new_rule
$1 : $$(call $2,$1)
        $$(CC) -c $$(CFLAGS) $$< -o $$@
endef

# Example use
targets = foo bar biz

foo_prereq = foo1 foo2 foo3
bar_prereq = $(addsuffix .xx,$1)
biz_prereq = $(addprefix $1,.a .b .c)

$(foreach T,$(targets),$(eval $(call new_rule,$T,$T_prereq)))


You can of course also add other callbacks, for the target, recipe, etc.

Personally I'm not convinced this is useful in general... it's certainly a lot less readable (to me).  But if you had one set of global makefiles that defined all the templates, etc. then used data-driven variable assignments to do the rest I suppose it might be useful.

Paul D. Smith <psmith>
Group administrator
Thu 22 Jun 2017 07:50:46 PM UTC, comment #3: 

Another example by Mike Gran:

demo: $(guile (root->list-of-objects "demo"))
        $(CC) $(LDFLAGS) -o $@ $^


You showed an other interesting use case. It seems that only simple input file dependencies would be constructed.
I guess that the concrete function parameter "demo" can also be replaced by a corresponding variable reference.

It fits only partly to the proposed software extension which should perform generation of make rules similar to static pattern rules.


I imagine that it will become a general software development challenge to achieve consensus for the required parameters of such callback functions (and the corresponding notation).

Markus Elfring <elfring>
Thu 22 Jun 2017 05:32:45 PM UTC, comment #2: 

Is this what you mean?

CFLAGS = -g -O2 -Wall

all: demo

define GCOMP2
(define (root->list-of-objects target)
  (list (string-append target "_foo.o")
        (string-append target "_bar.o")))
#f
endef

$(guile $(GCOMP2))

demo: $(guile (root->list-of-objects "demo"))
        $(CC) $(LDFLAGS) -o $@ $^

Mike Gran <mike121>
Thu 22 Jun 2017 03:21:02 PM UTC, comment #1: 

Example by Mike Gran:

$(objects):
        $(foreach X,$@,\
        $(guile (gcomp "$(X)")))
        @true


I would like to see a kind of function call for the specification of prerequisites (instead of the shown function calls in the recipe).

A variant of the shown small Guile source file might be usable for the proposed usage of a corresponding callback function.

Markus Elfring <elfring>
Thu 22 Jun 2017 01:10:13 PM UTC, original submission:  

Static pattern rules can be used like in the following example.


objects::=foo.o bar.o

$(objects): %.o: %.c
        $(CC) -c $(CFLAGS) $< -o $@



Such a specification seems to indicate that the placeholder “%” can only be mapped to a stem if the passed targets contain the same suffix (and/or prefix) which was also specified by the target pattern.
I find that this approach requires then the use of duplicate data. I would prefer to avoid that because of general software design principles.

I would prefer in some use cases to work directly with the targets list in the way by appending (or prepending) something to a file name (instead of performing the previous data extraction operation).

I imagine that an other syntax variant could express additional possibilities for a better handling of desired prerequisites there. I suggest to let customisable callback functions decide which data transformations should be finally applied.

How do you think about to add support for such advanced generation of make rules?

Markus Elfring <elfring>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #41027:  makefile added by mike121 (163B - application/octet-stream - Here's one way of doing it. Note that I don't work on Make. I just thought is was an interesting hack question.)
file #41028:  gcomp.scm added by mike121 (364B - text/x-scheme - Here's one way of doing it. Note that I don't work on Make. I just thought is was an interesting hack question.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by mike121 (Updated the item)
  • -email is unavailable- added by elfring (Submitted the item)
  •  

    There are 0 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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-07-02 psmith StatusNone Wont Fix
        Open/ClosedOpen Closed
    2017-06-22 mike121 Attached File- Added makefile, #41027
        Attached File- Added gcomp.scm, #41028

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code