[bug #51338] Support for construction patterns by make functions

Follow-up Comment #7, bug #51338 (project make): > > 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

Re: [bug #51309] Determination of a file list from a single folder without changing the working directory

> Are you able to provide any example proving how it matters under some more > or less rare circumstances? I guess not at the moment. > Or do you find the current software good enough I dared to point some change possibilities out recently. > and no changes needed? It depends on your views

Re: [bug #51309] Determination of a file list from a single folder without changing the working directory

On Sun, 2 Jul 2017 16:14:31 -0400 (EDT) Markus Elfring wrote: > It might matter more under other circumstances. Are you able to provide any example proving how it matters under some more or less rare circumstances? > (The current software can be fast enough to some

[bug #51309] Determination of a file list from a single folder without changing the working directory

Follow-up Comment #9, bug #51309 (project make): I suggested also a comparison of two algorithms . * A simple time measurement can also show test results for which you might not be looking for. * The usage of data structures like

[bug #51309] Determination of a file list from a single folder without changing the working directory

Follow-up Comment #8, bug #51309 (project make): If, for example, you can show an example of notdir adding significantly to the amount of time the make program takes. To test this I created a makefile like this: foo = ... all: ; : $(words $(foo)) where the "..." represents 6000 paths

[bug #51338] Support for construction patterns by make functions

Follow-up Comment #6, bug #51338 (project make): > …, 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

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

Follow-up Comment #8, bug #51292 (project make): > 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

[bug #51338] Support for construction patterns by make functions

Follow-up Comment #5, bug #51338 (project make): > 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

[bug #51306] Checking programming possibilities around “MAKECMDGOALS”

Follow-up Comment #4, bug #51306 (project make): But the make rule set can be adjusted in some ways according to the query result. ___ Reply to this item at:

[bug #51306] Checking programming possibilities around “MAKECMDGOALS”

Follow-up Comment #3, bug #51306 (project make): You can't change the set of goals that make will build by modifying the MAKECMDGOALS variable. All you can do is query which goals it will build. ___ Reply to this item at:

[bug #51338] Support for construction patterns by make functions

Follow-up Comment #4, bug #51338 (project make): > 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

[bug #51311] Checking search retries for implicit make rules

Follow-up Comment #4, bug #51311 (project make): > In fact there can be zero, one, or as many prerequisites containing the pattern character as you like. Essentially if the target contains a pattern character then it's a pattern rule: Can examples in the manual cause the impression that there is

[bug #51338] Support for construction patterns by make functions

Update of bug #51338 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #3: Secondary expansion

[bug #51306] Checking programming possibilities around “MAKECMDGOALS”

Follow-up Comment #2, bug #51306 (project make): I imagine that there is a need to express higher level requirements. If you know for example that parameter like “distclean” was passed somewhere in the list of make goals, I guess that it can make sense to omit the execution of previous targets

[bug #51311] Checking search retries for implicit make rules

Update of bug #51311 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #3: As pointed out on the

[bug #51306] Checking programming possibilities around “MAKECMDGOALS”

Update of bug #51306 (project make): Item Group: Bug => Documentation ___ Follow-up Comment #1: The same way you'd check for a word in any other list of words, in GNU make: sources = foo.c

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

Follow-up Comment #7, bug #51292 (project make): > 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

[bug #51297] Better support for escaping of function parameters

Update of bug #51297 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #1: It's important to

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

Follow-up Comment #6, bug #51292 (project make): Was your feedback truncated by the tracking interface for this issue? ___ Reply to this item at: ___

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

Follow-up Comment #5, bug #51292 (project make): 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

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

Update of bug #51292 (project make): Status:None => Wont Fix Open/Closed:Open => Closed ___ Follow-up Comment #4: You can easily add

[bug #51309] Determination of a file list from a single folder without changing the working directory

Follow-up Comment #7, bug #51309 (project make): > (a) you prefer to do it this way rather than the currently supported method of post-processing the wildcard results, … Yes. >(b) there's a significant performance benefit to avoiding the extra processing. I find that the difference can be

[bug #51309] Determination of a file list from a single folder without changing the working directory

Follow-up Comment #6, bug #51309 (project make): A theoretical argument is not what Paul meant by "actual results". Have you measured the time spent adding and removing the directory names in some realistic case? If not, then please do not advocate for making Make bigger..

[bug #51309] Determination of a file list from a single folder without changing the working directory

Follow-up Comment #5, bug #51309 (project make): I understand what you are suggesting. But I don't see any need to add new capabilities for this when the existing features of GNU make can already give these results. The only reasons for it that I can see would be (a) you prefer to do it this

[bug #51278] Support for the specification of special build properties together with each make rule

Follow-up Comment #2, bug #51278 (project make): > .SUFFIXES is an entirely different thing and doesn't belong on this list: it doesn't modify a target. Is this target relevant for suffix rules? >.SECONDEXPANSION is a boolean flag for the entire make process, it doesn't apply to specific

[bug #51309] Determination of a file list from a single folder without changing the working directory

Follow-up Comment #4, bug #51309 (project make): I repeat my argument from 26. June: https://lists.gnu.org/archive/html/bug-make/2017-06/msg00198.html If the desired directory on which a file filter should be applied could be selected before, the file names would not contain references to this

[bug #51278] Support for the specification of special build properties together with each make rule

Update of bug #51278 (project make): Status:None => Wont Fix Open/Closed:Open => Closed ___ Follow-up Comment #1: .SUFFIXES is an

[bug #51269] Reusing data from targets for prerequisites

Follow-up Comment #2, bug #51269 (project make): I would also like to restrict secondary expansion (or evaluation?) to specific make rules which might not fit to the following information. “… In order for this second expansion to occur, the special target .SECONDEXPANSION must be defined before

[bug #51309] Determination of a file list from a single folder without changing the working directory

Follow-up Comment #3, bug #51309 (project make): There's no question that FOO := $(notdir $(wildcard Bau/*.txt)) is more efficient than: ~/Projekte> $(cd Bau && echo "echo $(ls *txt)") because the latter involves starting a whole new shell (two, technically) while the former is handled

[bug #51269] Reusing data from targets for prerequisites

Update of bug #51269 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: The secondary

[bug #51309] Determination of a file list from a single folder without changing the working directory

Follow-up Comment #2, bug #51309 (project make): I disagree with the run time characteristics of the mentioned functionality for my special use case. ~/Projekte> $(cd Bau && echo "echo $(ls *txt)") MOTD.txt Can a similar data processing operation be performed faster by advanced make

[bug #51267] Improve error handling after a special command

Update of bug #51267 (project make): Item Group: Bug => Documentation ___ Reply to this item at: ___

[bug #51309] Determination of a file list from a single folder without changing the working directory

Update of bug #51309 (project make): Status:None => Wont Fix Open/Closed:Open => Closed ___ Follow-up Comment #1: The current