bugmake - Bugs: bug #51338, Support for construction patterns...

 
 

bug #51338: Support for construction patterns by make functions

Submitter:  Markus Elfring <elfring>
Submitted:  Thu 29 Jun 2017 05:55:34 AM UTC
   
 
Severity:  3 - Normal Item Group:  Enhancement
Status:  Not A Bug 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

Mon 03 Jul 2017 06:54:21 AM UTC, comment #8: 


> …, including POSIX-compliant makefiles as well as GNU make-specific makefiles.


I contributed also a bit in this area.


> In any event, the bug tracker is not the place for that discussion.


It seems that it will occasionally happen to “loose” the context for a topic if an issue number was not registered for it.


> …, is it possible to define new built-in make functions then sure, …


I hope that our constructive dialogue can result into such software development results (together with documentation extensions).


I started with an example (which is simple enough to be reusable) for this issue. I could include adjusted variants into various make scripts as needed.

But design/construction patterns can be also so simple in some cases so that they will be “included” (or just applied) somehow again. Will it become more useful to agree on corresponding (function) names then?

Markus Elfring <elfring>
Sun 02 Jul 2017 09:19:45 PM UTC, comment #7: 


> > it's basically a request to "please make things better".


> Yes, this is also true.


Well, I'm not personally interested in re-designing makefiles.  The makefile syntax has a lot of problems: no one would suggest that it doesn't.  However, make has existed for over 40 years and GNU make has existed at least 30 years.  There are literally millions of makefiles currently being used, including POSIX-compliant makefiles as well as GNU make-specific makefiles.

Make has its niche and I'm not interested in turning it into something completely different in an effort to break it out of that niche: it has too much baggage for that to be feasible.  Many alternatives to make have been created by people frustrated with the limitations of makefiles; if you want a build control language with a fundamentally different syntax I urge you to look into the alternatives to make and see if one of them might work better for you than makefiles.

In any event, the bug tracker is not the place for that discussion.

> Can the make function library be an update candidate?


If you mean, is it possible to define new built-in make functions then sure, if they're sufficiently useful, needed, differentiated, etc.

Paul D. Smith <psmith>
Group administrator
Sun 02 Jul 2017 07:43:00 PM UTC, comment #6: 


> …, but I can't tell exactly what aspects of the current capabilities you want to be different.


This one is more a feature request.


> That's not a design,


But I find that a selection of two rules could fit into this area.


> it's basically a request to "please make things better".


Yes, this is also true.

Can the make function library be an update candidate?


> … examples of a new makefile syntax …


I expressed such a desire in other issues. But this issue belongs more to the clarification for general design patterns of the make software.


> … you spend a huge amount of time …


It is a simple approach so far. The efforts might increase as usual during our constructive dialogue.


> … so they must be more than just a slightly different way to get the same results.


Can you get into the mood to clarify the application of design/construction patterns a bit more for make?

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


> I suggest to give some make rule combinations (pairs, trios, …) another look.


That doesn't constitute a specific design.  You've provided an example of makefile syntax that works today, in your initial description.  Clearly you are not satisfied with that since you opened this bug report, but I can't tell exactly what aspects of the current capabilities you want to be different.  After the example you point to a number of general concepts (which are not clearly related) and then suggest we "give them another look".  That's not a design, it's basically a request to "please make things better".

When I say a specific design I mean, one or more actual examples of a new makefile syntax that would work better for your purposes than the syntax which is currently available, and a description of precisely how the examples should be interpreted.  I'm not suggesting you implement it, or even that it be completely consistent.  Indeed I don't recommend you spend a huge amount of time on it because unless it's many times better than what we have already I doubt it would be acceptable; as I mentioned before there's a huge cost to adding new features so they must be more than just a slightly different way to get the same results.

But without SOME sort of concrete example of what you are thinking about, we are at an impasse.

Paul D. Smith <psmith>
Group administrator
Sun 02 Jul 2017 06:20:17 PM UTC, comment #4: 


> You don't need to use secondary expansion inside the recipe, because you already have access to the automatic variables like $@ there.


I thought about a need for a “second expansion” (for a moment) while it could be implemented in the mentioned use case by another variable evaluation (call of the make function “eval”).


> If you have a specific design in mind please post it here with explicit examples and discussion of exactly how it would work and I'll reopen this enhancement request.


I tried this way.

I suggest to give some make rule combinations (pairs, trios, …) another look.
Which of them can become part of a higher level make standard library?

Markus Elfring <elfring>
Sun 02 Jul 2017 05:49:24 PM UTC, comment #3: 

Secondary expansion is a shorthand that allows you to use some automatic variables in the prerequisites list (most commonly $@) so that you can modify the prerequisites based on the target name.  It is a simplified method to generate make rules in a limited way, without resorting to full-fledged eval which provides a superset of secondary expansion's capabilities.  You might consider reading (starting from the oldest and going to the newest) the set of blog posts here: http://make.mad-scientist.net/category/metaprogramming/ which describe ways to define make rules that have some amount of variability.

You don't need to use secondary expansion inside the recipe, because you already have access to the automatic variables like $@ there.

In your situation you are creating entire rules using a defined template with eval, so you have no need of secondary expansion there either: you can access any value that was used in the target list directly (this is what Martin is telling you).

I don't understand what you mean by "such approaches would be directly distributed with the make software", but I don't want to use the bug tracker to design a new feature from scratch.  If you have a specific design in mind please post it here with explicit examples and discussion of exactly how it would work and I'll reopen this enhancement request.  If you're asking for someone else to design a new feature based on an abstract description of your needs please use the mailing lists to discuss it.

Paul D. Smith <psmith>
Group administrator
Thu 29 Jun 2017 07:17:24 AM UTC, comment #2: 


> You can do that today, no need for any enhancement.


I was also unsure about differences in the desired application of “second expansion”.

I have shown a bit with the code example that special build rule combinations can be implemented with make functions already.
I imagine that their run time characteristics can be different (or even better?) when such approaches would be directly distributed with the make software.

Would it make sense to provide any higher level build functions in a corresponding kind of standard library?

Markus Elfring <elfring>
Thu 29 Jun 2017 06:29:12 AM UTC, comment #1: 


> the code which will be evaluated in the recipes can be configured

by function call parameters

You can do that today, no need for any enhancement.

> I guess that I need to use the functionality “second expansion” then.


No.  https://www.gnu.org/software/make/manual/html_node/Eval-Function.html

Martin Dorey <mdorey>
Thu 29 Jun 2017 05:55:34 AM UTC, original submission:  

I can construct functions like the following for execution within make scripts.


my_preparation?=cat
my_compilation?=echo
my_dependencies_1?=a b c
my_dependencies_2?=x y z
my_targets?=Good luck
footer?=Test!

define rule_combination_1 =
${2}.in: ${1}
        $$(my_preparation) "1: $$<" > $$@

$(2).txt: $(1) ${2}.in
        $$(my_compilation) "2: $$$$(cat $$< $${footer})" > $$@
endef

$(info $(call rule_combination_1,$(my_dependencies_1),MOTD))

define static_rule_combination_2 =
$(addsuffix .in,$(2)): %.txt: %.in ${1}
        $$(my_preparation) "1: $$<" > $$@

$(addsuffix .msg,$(2)): %.msg: %.txt %.draft ${1}
        $$(my_compilation) "2: $$$$(cat $$< $${footer})" > $$@
endef

$(info $(call static_rule_combination_2,$(my_dependencies_2),${my_targets}))



It seems that such a code example is relatively simple. It tries to express
a general design pattern as make functions:
A data processing step depends on two input files (at least) from which one of
them (at least again) was automatically generated by a previous process.

I find that there are more software development possibilities to consider.

If I would like to extend this approach in the way that it becomes more generic
so that the code which will be evaluated in the recipes can be configured
by function call parameters, I guess that I need to use the functionality
“second expansion” then.
It seems that such “secondary expansion” is only directly supported for
prerequisites so far.

Now I imagine that it would be nice if the make software could help a bit more
in this use case.


There are also some programming languages available which can be executed from
two file formats.


Make scripts can support them by a pair of software build rules.

Other data formats (like documentation) are also used where the number of
desired generated end products is even bigger.


So I imagine that there can be a need to move some common functionality into
the make software infrastructure.
How do you think about to support it by extensions for the make function library?

Markus Elfring <elfring>

 

(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 psmith (Posted a comment)
  • -email is unavailable- added by mdorey (Posted a comment)
  • -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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-07-02 psmith StatusNone Not A Bug
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code