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

[Paul D. Smith]

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 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.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[SF Markus Elfring]

> 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 for software developments which your prefer.

I imagine that algorithm comparisons can lead to related improvements,
can't they?

Regards,
Markus

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Henrik Carlqvist]

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 degree.)

Or do you find the current software good enough and no changes needed?

regards Henrik

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Markus Elfring]

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 list and trees has got also different run
time characteristics. Each of them can have a corresponding application
domain.
* Which test environments would you find representative?


> From this I conclude that the performance impact of an additional notdir
function is negligible and there's no performance advantage to avoiding it.

It might matter more under other circumstances. (The current software can be
fast enough to some degree.)

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Paul D. Smith]

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 hardcoded into the makefile.  I then ran
"time make":


$ time make
: 6000

real0m0.004s
user0m0.000s
sys 0m0.000s


Then I modified the makefile to add a notdir like this:


foo = $(notdir ...)

all: ; : $(words $(foo))


where the "..." is the same as last time.  I got this result:


$ time make
: 6000

real0m0.004s
user0m0.000s
sys 0m0.000s


Same time.  This means that the amount of time needed to run notdir on 6000
paths is less than 1/1000th of a second.  From this I conclude that the
performance impact of an additional notdir function is negligible and there's
no performance advantage to avoiding it.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Markus Elfring]

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 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?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Paul D. Smith]

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 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))



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Paul D. Smith]

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 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.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Markus Elfring]

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:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Paul D. Smith]

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:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Markus Elfring]

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 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?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Markus Elfring]

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 any limitation?


>…, the reason your example doesn't work is that a pattern character must
match at least one character.

Can this information appear in another section of the manual?

Do I need to pair standard pattern rules with concrete make rules so that the
placeholder “%” will be handled in special cases as if it would be
optional?

I am curious on how the software will evolve further for the previous
clarification request “pattern rules: % doesn't match empty string”
 then.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Paul D. Smith]

Update of bug #51338 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up 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.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Markus Elfring]

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 while subsequent targets could be updated
again.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Paul D. Smith]

Update of bug #51311 (project make):

  Status:None => Duplicate  
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

As pointed out on the mailing list, it's not true that there can only be one
prerequisite containing the pattern character (%).  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: the prerequisites list doesn't matter.

As Mike points out, the reason your example doesn't work is that a pattern
character must match at least one character.

As for allowing pattern characters to match zero characters, that is already
filed as an enhancement request as bug #29448 so we don't need another one.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Paul D. Smith]

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 bar.c

ifeq (,$(filter clean,$(MAKECMDGOALS)))
include $(sources:.c=.d)
endif


will only include the files if "clean" doesn't appear anywhere in
MAKECMDGOALS.

However, I'm not sure that this is the correct behavior.  Suppose someone used
"make clean all"; now none of the dependency files will be included for the
"all" target.

I'll leave this open as a Doc bug to determine whether the example needs to be
reworked.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Markus Elfring]

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 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.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Paul D. Smith]

Update of bug #51297 (project make):

  Status:None => Duplicate  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

It's important to understand that in GNU make (unlike the shell, for example)
splitting of arguments in function invocations is done _before_ the arguments
are expanded.

So, you don't have to worry about special characters embedded in variables
making a hash of your expansion.  If they're not present directly in the call,
they're not special.

So for example, this works fine:


foo = abcd, 234, (fo"o), bar'))

show = 1: |$1|

$(info $(call show,$(foo)))


will show:


1: |abcd, 234, (fo"o), bar'))|


This is true of all make functions that take arguments.  As a result there's
very little reason to need something that will escape a string, to keep it
from being interpreted by make functions.

It is useful to be able to escape whitespace and some other characters, in
some contexts (but this is NOT needed to delimit arguments to make functions).
 But that's bug #712 as already noted, so we don't need another bug for this.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Markus Elfring]

Follow-up Comment #6, bug #51292 (project make):

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

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Paul D. Smith]

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 and call:


# Function to generate a new rule.
# Call syntax: $(call new_rule,,)
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.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Paul D. Smith]

Update of bug #51292 (project make):

  Status:None => Wont Fix   
 Open/Closed:Open => Closed 

___

Follow-up 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:


# Function to generate a new rule.
# Call syntax: $(call new_rule,,)
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.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Markus Elfring]

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 eventually measured.

We have got different opinions about the circumstances when it would be
significant enough.


> … adding new features in a backward- and POSIX-compatible way is difficult
due …

How many software developers would dare to extend corresponding programming
interfaces so that they can be better reused by the make function library?

I am curious if this story could ever turn into a more promising “maybe”
thing.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Martin Dorey]

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..

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Paul D. Smith]

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
way rather than the currently supported method of post-processing the wildcard
results, or (b) there's a significant performance benefit to avoiding the
extra processing.  For (a), I'm not inclined to create new capabilities just
for this reason.  For (b), I seriously doubt that there will be any measurable
performance difference in a real makefile.

If you can show an example where there _is_ a significant performance
difference then we can discuss that.

To be clear, my attitudes on makefile syntax are that (1) it's already complex
and there are already a lot of features, complexities, and "gotchas", (2)
adding new features in a backward- and POSIX-compatible way is difficult due
to the relatively free-form syntax of makefiles, and (3) features combine in
ways that are multiplicative, not additive, which greatly increases the
potential for incorrect interactions, bugs, and the testing needed to support
them.

Thus, my initial answer to adding new capabilities is almost always going to
be "no".  It requires a clear improvement in power (not just syntactic sugar)
and a reasonable syntax that makes sense and doesn't break lots of existing
makefiles to clear that hurdle and get to "maybe" or "yes".

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Markus Elfring]

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 targets.

I would appreciate if such a software detail can be adjusted anyhow.


> I think it's fine to have them specified on a separate line.

I imagine that it could be occasionally more appropriate to specify special
make rule properties in the same line (at the beginning) so that the
repetition of target names could be avoided.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Markus Elfring]

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 directory
and another function call is therefore unnecessary to remove it from the
returned list elements.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Paul D. Smith]

Update of bug #51278 (project make):

  Status:None => Wont Fix   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

.SUFFIXES is an entirely different thing and doesn't belong on this list: it
doesn't modify a target.

.SECONDEXPANSION is a boolean flag for the entire make process, it doesn't
apply to specific targets.

I don't see any straightforward syntactic way to include the per-target
special modifiers within the rule.  I think it's fine to have them specified
on a separate line.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #51269] Reusing data from targets for prerequisites

[Markus Elfring]

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 the first prerequisite list that makes
use of this feature.
…”


Are there any further software development challenges to consider so that such
functionality will only be switched on for a specific scope in a make script?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Paul D. Smith]

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 entirely within the make process with no fork/exec
operation required.

If you can show actual results where adding the notdir makes a significant
performance difference in a makefile environment we can reconsider, but I'm
not interested in adding new features duplicating existing capabilities
without proof that there's a real need.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #51269] Reusing data from targets for prerequisites

[Paul D. Smith]

Update of bug #51269 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

The secondary expansion feature already provides this capability.  That's what
it's for.

https://www.gnu.org/software/make/manual/html_node/Secondary-Expansion.html

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Markus Elfring]

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
functions?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Paul D. Smith]

Update of bug #51267 (project make):

  Item Group: Bug => Documentation  


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Paul D. Smith]

Update of bug #51309 (project make):

  Status:None => Wont Fix   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

The current capabilities (using notdir to remove the entire directory, or
using patsubst etc. to remove partial directories) is sufficient.  Nothing new
is needed here.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make