Follow-up Comment #6, bug #106 (project make):
Don't worry about it. I think I have a handle on it.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=106
___
Follow-up Comment #15, bug #15757 (project make):
Good stuff. Having both of those lists eventually point to global_setlist
is, I'm pretty sure, quite correct... all local setlists should eventually
point to the global list (this allows global variables to be accessed after
all!) I'll have to
Update of bug #15757 (project make):
Severity: 3 - Normal = 5 - Blocker
Assigned to:None = psmith
___
Reply to this item at:
Follow-up Comment #17, bug #15757 (project make):
Oh yeah... using the info you gave and just walking through the logic of
merge_variable_set_lists(), you can easily see where the problem happens:
global_setlist-next pointer is getting set to point into the to setlist.
Ouch. The logic in this
Follow-up Comment #18, bug #15757 (project make):
Hi. I can now reproduce this problem, even on Linux, using the following
setup:
mkdir t1 t2
touch t1/rules.mk
cd t2
cat Makefile EOF
VPATH = ../t1
include rules.mk
.PHONY: all
all: foo.x
foo.x : rules.mk ; @echo cp $ $@
rules.mk : MYVAR = foo
Follow-up Comment #19, bug #15757 (project make):
OK. Please try replacing version.c:merge_variable_set_lists() with the one
I've attached to this bug report. See if that solves your problem. It fixes
my test case but the regression tests all still pass.
Additional Item Attachment, bug #15757 (project make):
File name: mvnew.cSize:0 KB
New version.c:merge_variable_set_lists() function
http://savannah.gnu.org/bugs/download.php?item_id=15757item_file_id=3408
___
Update of bug #15757 (project make):
Status:None = Fixed
Open/Closed:Open = Closed
Component Version:None = 3.80
Fixed Release:
:-/.
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
Please remain calm...I may be mad, but I am a professional. --Mad Scientist
=memcheck --leak-check=full \
make -k -j 4 variants=dyn_dbg --warn-undefined-variables everything
It will be slow: twice as slow or more. But, it's a great tool.
Thanks.
--
---
Paul D. Smith [EMAIL PROTECTED
in the original text, before expansion.
I'll add a note about this as it's a behavior change, even though I
consider it a bug fix.
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at:
http://www.gnu.org
Update of bug #15818 (project make):
Assigned to:None = psmith
___
Follow-up Comment #2:
Ah! Any reproducible test case is extremely useful. OK, this bug is not
difficult to see.
worried might break something that I can't test easily.
So, if you could find some time to verify (or not) this patch before the
weekend that would be great!
Cheers!
--
---
Paul D. Smith [EMAIL PROTECTED] Find
Thanks for testing this.
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
Please remain calm...I may be mad, but I am
Thanks Steve;
It seems like your problems are all on Windows-type systems, not
UNIX-type systems: you might have better luck posting them on the
make-w32@gnu.org mailing list.
--
---
Paul D. Smith [EMAIL PROTECTED
Update of bug #15913 (project make):
Assigned to:None = psmith
___
Follow-up Comment #1:
Please see this reply I sent to the original message on the bug-make mailing
list:
?
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
Please remain calm...I may be mad, but I am a professional. --Mad Scientist
___
Bug-make mailing list
Bug-make
Follow-up Comment #2, bug #15919 (project make):
Not offhand. I haven't looked at it carefully enough. I did spend about 10
mins: just enough to verify that I can reproduce it. I also enabled
debugging and I can see that it's looping forever, not just hanging. Make
seems to think that it's
.
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
Please remain calm...I may be mad, but I am a professional. --Mad Scientist
Follow-up Comment #13, bug #15718 (project make):
Well, you can't assume that just because _on UNIX_ make forcibly adds a -c to
every $(SHELL) invocation, that it also does the same thing in the other
ports. There's a lot of special code to handle different types of shell on
Windows; Eli etc.
download and unpack it):
ftp://alpha.gnu.org/gnu/make/make-3.81rc1.tar.gz
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at:
http://www.gnu.org http
tries to run the h;y/[a-z]/[A-Z]/
rl thing through /bin/sh instead of sed. This doesn't appear to be a
rl sed problem, but a make problem.
I'll need more info about this before I can give an opinion.
--
---
Paul D
!
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
Please remain calm...I may be mad, but I am a professional. --Mad Scientist
___
Bug-make
Follow-up Comment #1, bug #16002 (project make):
The kernel 2.6 build environment is relying on an incorrect behavior of GNU
make which was fixed in the latest rc1. We're trying to determine what to do
about it now.
For more information please see:
Update of bug #15937 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
.
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
Please remain calm...I may be mad, but I am a professional. --Mad Scientist
Follow-up Comment #18, bug #15718 (project make):
OK, I've applied Eli's patch.
This bug/thread has gotten way out of control: I can't determine what's
actually a real problem and what's just a misunderstanding. Can one or more
of the principles followup with a comment clarifying what the real
)/%.o: $(srcdir)/%.c |$(objdir)/dir
...
Obviously, though, this is a bug that needs to be fixed.
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at:
http://www.gnu.org
Update of bug #15942 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
URL:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=16051
Summary: Non-existent prerequisites are not included in $?
Project: make
Submitted by: psmith
Submitted on: Thu 03/09/06 at 20:55
Severity: 3 - Normal
Update of bug #16002 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Follow-up Comment #5, bug #15942 (project make):
I believe normal W32 was fixed in rc1, and cygwin builds will be fixed in the
next release.
Perl provides a way to test whether the system supports symlinks and that's
what I use originally. For some reason, though, the Windows port of Perl
Follow-up Comment #3, bug #15942 (project make):
They are already disabled on any system where the $port_type is W32, and/or
any system where symlinks don't work. You can test this in Perl but the
Windows port of Perl reports that they do work (odd).
If you find that this isn't working please
Follow-up Comment #2, bug #16051 (project make):
Well, I thought about this. However, I don't really want to introduce a
temporary target then deprecate it again. Also, this problem has existed in
virtually every version of GNU make and no one mentioned it until late last
year, so I think it
Update of bug #15938 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #15947 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #15968 (project make):
Item Group: Bug = Enhancement
___
Follow-up Comment #1:
Hm. I'm not sure that there's anywhere in the make manual that says or
implies that simply
Update of bug #16088 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #1:
This is a duplicate of
Update of bug #15913 (project make):
Status:None = Fixed
Open/Closed:Open = Closed
Fixed Release:None = CVS
Follow-up Comment #2, bug #16053 (project make):
Hm. I don't know if we can release 3.81 with this kind of regression: it's
different than releasing with a bug in new behavior or with an old bug not
fixed.
Another idea which would resolve this problem but not the general case (when
Update of bug #16108 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
OK, I put something similar to this in for the next release.
Thanks.
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
Update of bug #16132 (project make):
Status:None = Works for me
___
Follow-up Comment #1:
I can't reproduce this on GNU/Linux; both rc1 and the latest CVS code work
fine. Please provide
-END PGP SIGNATURE-
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
Please remain calm...I may be mad, but I am
Update of bug #16118 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
As best as I can tell
Update of bug #16138 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Follow-up Comment #5, bug #16132 (project make):
Can you please remove the @ prefix from your echo commands, and then re-run
your test. Show us the output make prints (which are the commands that it's
sending to the shell) against the command you expect to be run and what
actually gets invoked
Follow-up Comment #2, bug #16140 (project make):
If it's a simple-enough change and doesn't cause problems with the regression
tests it's fine with me to fix it. Do you have access to valgrind and/or
gprof to check the performance etc.?
Follow-up Comment #3, bug #16145 (project make):
I think you have two choices, at least one of which should work :-). Either
way I think you have to get the .SECONDARY: global target out of there.
Anyway, you can do two things: first, you can mention all the files that
would otherwise be
Update of bug #16145 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #5:
Ok, closing as per
Update of bug #16170 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Follow-up Comment #20, bug #16132 (project make):
Pieter: thanks for debugging this, it's very helpful! I'd like to do
something with this bug before the release (which is imminent) if possible;
is it not a bug after all?
I notice that the change to include echo in the BATCH_MODE_ONLY_SHELL
accordingly.
Cheers!
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
Please remain calm...I may be mad, but I am
rule recursion.
Avoiding implicit rule recursion.
No implicit rule found for `a/b/c/libz.so'.
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at:
http://www.gnu.org http
it as a bug with a
group of Enhancement on the Savannah project page for GNU make. I
can't guarantee anything will happen but it's the best way to get
something like this considered for the future.
--
---
Paul D. Smith [EMAIL
.
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
Please remain calm...I may be mad, but I am a professional. --Mad Scientist
Update of bug #16236 (project make):
Item Group:None = Documentation
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:
Update of bug #16132 (project make):
Status:Works for me = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #22:
I looked at
Update of bug #106 (project make):
Fixed Release: CVS = 3.81
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=106
Update of bug #108 (project make):
Fixed Release: CVS = 3.81
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=108
Update of bug #127 (project make):
Fixed Release: CVS = 3.81
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=127
Follow-up Comment #8, bug #9062 (project make):
Even simpler is to look at the NEWS file; all user-visible changes should be
documented there:
Version 3.80
...
* A new built-in variable is defined, $(MAKEFILE_LIST). [...]
...
Version 3.77
...
* Make defines a new variable, CURDIR,
Follow-up Comment #3, bug #8297 (project make):
Yes, but I don't like that syntax because it seems to allow both kinds of
rules to be defined at the same time; consider:
foo + bar baz boz + biz:
What does this mean? In discussions on the GNU make developers' list we
discussed a syntax like
on the make-w32@gnu.org mailing list to see if
they have any advice there... this is a Windows-specific issue and they
know much more about Windows than the folks reading this list.
Good luck!
--
---
Paul D. Smith [EMAIL
Follow-up Comment #10, bug #9062 (project make):
GNU make does not and has never supported a built-in variable $(PWD).
Of course, GNU make does now and has always (just like every other make)
imported environment variables exported from the invoking process into GNU
make variables, and some
, but the only way to know for sure is if someone
can tell us in which part of GCC the multilib is built so we can look
at it.
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at:
http://www.gnu.org
Follow-up Comment #11, bug #14684 (project make):
This is pretty clearly a bug in Solaris; the POSIX spec says:
blank
Define characters to be classified as blanks.
In the POSIX locale, only the space
/newline pair in the script sent to the shell. See the NEWS file.
I'm not 100% sure why that's a syntax error, but...
n http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27023
--
---
Paul D. Smith [EMAIL PROTECTED
%% Ben Pfaff [EMAIL PROTECTED] writes:
bp Paul D. Smith [EMAIL PROTECTED] writes:
It looks like for Solaris 10 they introduced an implementation
of isblank() into the standard header files, which didn't used
to be there (it's not on my Solaris 8 system for example).
bp For what it's
Follow-up Comment #3, bug #16286 (project make):
All of the behavior you see, as far as I can tell, is expected. The
documentation of vpath shows that if the target needs to be rebuilt then the
vpath-qualified pathname is thrown away and the target is rebuilt locally
(which means that when this
Follow-up Comment #3, bug #105 (project make):
Closed support #105307 as a duplicate of this bug. See the details on that
support request because it's slightly different, but any solution for this
problem should ideally be hookable so that a generic re-ordering of
prerequisites is possible.
the GCC
makefiles already require GNU make.
You could add a setting of SHELL directly into the command script for
those rules where it makes a difference.
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU
Update of bug #16376 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
This behavior is as
don't lose track of
this.
Thanks!
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
Please remain calm...I may be mad, but I
OK, will do. Thanks.
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
Please remain calm...I may be mad, but I am
?
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
Please remain calm...I may be mad, but I am a professional. --Mad Scientist
___
Bug
they have some clue as to what operations might be causing
these errors.
Good luck!
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at:
http://www.gnu.org http
).
This mailing list is only for bugs in the GNU make program itself.
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
Please remain
Follow-up Comment #8, bug #16505 (project make):
I think the INTENT was to allow embedded newlines. However, the
implementation only works for tools which will ignore the backslash as well.
Some UNIX tools do this; many don't.
You _have_ to have the newline in the makefile, because make does
Follow-up Comment #9, bug #16505 (project make):
Argh. I mean You _have_ to have the BACKSLASH in the makefile, in the
second paragraph of the previous comment :-/
___
Reply to this item at:
URL:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=16545
Summary: Escaping a : in an escaped substition reference
on a prereq line dumps core
Project: make
Submitted by: psmith
Submitted on: Sunday 05/07/06 at 14:56
Follow-up Comment #3, bug #16531 (project make):
The OP is correct: it's not the %, it's the :. Because the variable
reference is escaped, make doesn't skip over it when parsing the command line
like it normally would, and instead make sees the second : inside the
substitution reference and
Update of bug #13479 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
to provide patches and do the testing. As long as it doesn't appear to
impact the other ports, I generally just apply patches which have been
agreed to by a quorum on the make-w32@gnu.org list.
--
---
Paul D. Smith [EMAIL
to see what that
actually means.
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
Please remain calm...I may be mad
%% George Wood [EMAIL PROTECTED] writes:
gw If you have enabled secondary expansion (see Section 3.10
gw [Secondary Expansion], page 19) and you want a literal dollar sign
gw in the prerequisites lise, you must actually write four dollar
gw signs (\x8C
Update of bug #17105 (project make):
Status:None = Works for me
Open/Closed:Open = Closed
___
Follow-up Comment #2:
This appears to be a
have been having lately.
It's all good!
Cheers!
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
Please remain calm...I
%% John W. Eaton [EMAIL PROTECTED] writes:
jwe On 28-Jul-2006, Paul D. Smith wrote:
| This would be very tricky: right now all the code to do DOS vs. POSIX
| pathnames is controlled through #ifdefs, so it's a compile-time thing.
| Changing it to a runtime thing would be a lot of work, I
Follow-up Comment #2, bug #17521 (project make):
Actually, Eli, if the example shown is accurate (I haven't tried it) then
this seems to be a bug. First note that the two cases behave differently:
the one without the semicolon strips the backslash and the one with it does
not. That can't be
Update of bug #17529 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Please see the GNU
Thanks; this will be fixed in the next version of GNU make.
Cheers!
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
Update of bug #17665 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
I do not know if this
Update of bug #17880 (project make):
Item Group:None = Documentation
___
Reply to this item at:
http://savannah.gnu.org/bugs/?17880
___
Message
Update of bug #16304 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #16577 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #16652 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #17701 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #17880 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #17883 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #2:
As Philip points out,
601 - 700 of 2097 matches
Mail list logo
