Follow-up Comment #5, bug #35485 (project make):
I don't think the stack-based approach is actually more runtime or space
intensive ...
I don't think so either. I just meant it would be a more intrusive change in
terms of diff size than the one-liner proposed here. But if you're that it's
not,
Follow-up Comment #4, bug #35485 (project make):
OK, let me put it another way: I don't think there's much value in creating a
new built-in variable which is just shorthand for something so easily defined
by the makefile author. If we add a new variable I'd prefer it solve a real
problem, and
On Sun, 2012-02-26 at 21:58 -0800, Howard Chu wrote:
You've just described an O(n^2) behavior. This is definitely a drag;
but it really depends on how heavily you make use of macros.
Well, in this case it depends on how heavily you make use of APPEND
operations on macros. Is it worth adding a
Follow-up Comment #3, bug #35485 (project make):
I'm not sure how much more specific I can be than saying that it's just
shorthand for $(abspath $(dir $(lastword $(MAKEFILE_LIST but let me try
to elaborate.
First, the variability of .MFDIR would be precisely the same as that of
MAKEFILE_LIST
Follow-up Comment #2, bug #35485 (project make):
I don't think this implementation is appropriate. The value of MFDIR will
change wildly over time if makefiles are included which can't possibly be what
you want. For example:
.MFDIR = $(abspath $(dir $(lastword $(MAKEFILE_LIST
$(info MFDIR
On Thu, 2012-02-09 at 17:25 +, Tim Murphy wrote:
I also think that it can be expensive to append things onto very long
lists in make but that's just suspicion and I really need to take a
proper look at it instead of making accusations.
Appending is not very expensive. Make doesn't know
Paul Smith wrote:
On Thu, 2012-02-09 at 17:25 +, Tim Murphy wrote:
I also think that it can be expensive to append things onto very long
lists in make but that's just suspicion and I really need to take a
proper look at it instead of making accusations.
Appending is not very expensive.
Hi,
I know this is tangential, but:
MAKEFILE_LIST itself is a problem for non-recursive builds because it
gets very big if you have a lot of include statements (as opposed to a
gigantic single makefile file).
Regards,
Tim
On 8 February 2012 18:30, David Boyce invalid.nore...@gnu.org wrote:
On Thu, Feb 9, 2012 at 5:33 AM, Tim Murphy tnmur...@gmail.com wrote:
Hi,
I know this is tangential, but:
MAKEFILE_LIST itself is a problem for non-recursive builds because it
gets very big if you have a lot of include statements (as opposed to a
gigantic single makefile file).
True, but
That resetting MAKEFILE_LIST trick is the thing is what works for us
- I should have said that's what we had to do (although more crudely)
instead of making you write out the solution :-). I just have this
feeling that it's a bit of a sharp corner in make when doing
non-recursive makefiles and I
Follow-up Comment #1, bug #35485 (project make):
T Murphy says:
I think that getting the directory of the current makefile is useful although
I am sure my team have had trouble with $(abspath) and the way it works in
some situations on windows (unfortunately our stuff has to work on both) - it
URL:
http://savannah.gnu.org/bugs/?35485
Summary: New $(.MFDIR) built-in variable
Project: make
Submitted by: boyski
Submitted on: Wed 08 Feb 2012 06:30:41 PM GMT
Severity: 3 - Normal
Item Group: Enhancement
12 matches
Mail list logo
