Follow-up Comment #7, bug #34832 (project make):
That function is used a lot in job.c, main.c, commands.c.
But I agree with Eli: what's the need for having this variable be thread-safe
in the first place? GNU make is not multithreaded (there would be a LOT of
work needed to make that possible).
Follow-up Comment #12, bug #34832 (project make):
The reason the buffer is static is that if you allocate a dynamic buffer,
someone has to free it. In POSIX we use the strerror() function which returns
a const pointer to a static string that never needs to be freed so there's no
facility in the
Follow-up Comment #17, bug #34832 (project make):
It is used:
make-cvs$ grep map_windows32_error_to_string *.c
commands.c:ierr, map_windows32_error_to_string (ierr));
job.c: error_string = map_windows32_error_to_string (er);
job.c: e,
Follow-up Comment #3, bug #34830 (project make):
Well, I can't test it because I have no Windows tools
Anyway the case statement is right. What it's trying to ask is if ANY value
in the list is no. The * will match zero or more chars, so this says,
basically, if the string /no/ appears
Follow-up Comment #5, bug #34830 (project make):
I already had a local fix for the configure disable thing; I was just waiting
to be sure the variable change worked for you.
Committed the changes so please try the latest.
___
Reply to
Follow-up Comment #2, bug #107 (project make):
Just to point out this works fine if you tell make to ignore errors during
builds using -include:
~$ cat /tmp/foo.mk
there: hi ; @echo there
a.mk: ; echo 'b.mk: ; echo hi: ; @echo hi $$@' $@
-include a.mk
-include b.mk
~$
Update of bug #35062 (project make):
Status:None = Wont Fix
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Sorry but this would
Update of bug #35133 (project make):
Item Group: Bug = Enhancement
___
Follow-up Comment #1:
The .PRECIOUS pseudo-target is behaving as documented:
You can also list the target pattern of an
Update of bug #35134 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #1:
You can get the
Follow-up Comment #9, bug #20501 (project make):
It's not completely true that -p shows the rules as if they were there.
Recall that there are two types of implicit rules in GNU make: suffix rules
and pattern rules.
If you use MAKEFLAGS+=-r then the _pattern rules_ will not be present in the
-p
Update of bug #20501 (project make):
Operating System: POSIX-Based = Any
___
Reply to this item at:
http://savannah.gnu.org/bugs/?20501
___
Message
Update of bug #20501 (project make):
Triage Status:None = Verified
___
Reply to this item at:
http://savannah.gnu.org/bugs/?20501
___
Message
Update of bug #35135 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
This is expected
Update of bug #35231 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Hi; this issue is
Follow-up Comment #1, bug #35248 (project make):
It looks to me like somewhere in your makefiles you are invoking make and
capturing its output and using that as part of the makefile so make is trying
to parse it. When you run make with -d it not only prints its normal output
that you expect,
Update of bug #35147 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #23928 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #4:
I believe this is
Update of bug #34832 (project make):
Assigned to:None = eliz
Triage Status:None = Small Effort
___
Reply to this item at:
Update of bug #35525 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
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
Update of bug #16670 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
URL:
http://savannah.gnu.org/bugs/?35711
Summary: Make needs to define targets earlier
Project: make
Submitted by: psmith
Submitted on: Sat 03 Mar 2012 02:01:17 PM EST
Severity: 4 - Important
Item Group: Bug
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
Update of bug #35410 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #35397 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #34530 (project make):
Status: Later = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #32485 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #30175 (project make):
Status:None = Not A Bug
Assigned to:None = psmith
Open/Closed:Open = Closed
Update of bug #35468 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Follow-up Comment #3, bug #35410 (project make):
I don't think the strlen() thing is worth the complexity: the average length
of a word passed to filter/filter-out is pretty small.
I did simplify the detection of filter vs. filter-out (and some other
functions as well) though.
Follow-up Comment #5, bug #35410 (project make):
I just don't believe the change will really save much. strlen() is pretty
darn efficient and trying to circumvent it has costs as well. With modern
compilers and architectures it's almost impossible to guess which sorts of
micro optimizations,
Update of bug #16545 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #12126 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #31361 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
Summary: MinGW make inexplicably invokes as.exe = gcc.exe is
deleting as file prematurely
Update of bug #34542 (project make):
Status:None = Works for me
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Closing as works for
Update of bug #36800 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Hi Serguei; this is a
Follow-up Comment #3, bug #36800 (project make):
Previously make didn't throw an error on the syntax. But the rule always had
the problem that the file you created was not the same as the one you told
make you'd create.
Most likely you never noticed this because with a prerequisite like all
Update of bug #36881 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #3:
3.82 is not a point
Follow-up Comment #5, bug #36881 (project make):
Sure but if you use the distro-provided program you should always use the
distro-provided documentation as well, not documentation you find on the web.
Distributions are by definition virtually always behind the upstream
development.
All distros
Update of bug #36987 (project make):
Open/Closed:Open = Closed
___
Follow-up Comment #1:
There's nothing related to GNU make, that I can see, in your problem
description.
Follow-up Comment #3, bug #36987 (project make):
No, I mean that this Savannah project supports the program GNU make, which is
a command-line tool used to manage the compilation of programs, or other
situations where one set of files needs to be converted to another set of
files in a way which
Update of bug #37069 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #36765 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #1:
This is a duplicate of
Update of bug #36529 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #36106 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #36925 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #36641 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #1:
This is a duplicate of
Update of bug #35764 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #35919 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Operating System:
Update of bug #36451 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #35248 (project make):
Item Group: Bug = Enhancement
Summary: When running in debug-mode (-d), make reports a
strange `multiple target patterns' error = Provide the ability to disable
debugging from the command line
Update of bug #35132 (project make):
Status:None = Works for me
Open/Closed:Open = Closed
Triage Status:None = Need Info
Update of bug #30653 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Component Version:
Update of bug #37208 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #1:
This is a duplicate of
Update of bug #36542 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Thank you for the
Update of bug #34309 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #31400 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #1:
This bug is no longer
Update of bug #32247 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #34167 (project make):
Triage Status:None = Need Info
___
Follow-up Comment #5:
Well, I don't have Purify available to me and I have no way to parse/read a
.pv file (I tried to
Update of bug #36844 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #7:
Closed as a duplicate
Update of bug #31847 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #5:
Based on the comments
Update of bug #30794 (project make):
Status:None = Wont Fix
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Based on Eli's comment
Update of bug #28426 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #1:
This is working
Update of bug #26864 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #4:
I believe this is a
Follow-up Comment #2, bug #36486 (project make):
This is a bug, but it's going to require some non-trivial effort to fix. The
problem is that make is recursively walking down (or up, whichever you like)
the variable sets, and when it pops back out it returns only the value string
of the expanded
Update of bug #32042 (project make):
Triage Status:None = Medium Effort
___
Follow-up Comment #1:
I agree this is a bug. I think fixing it will not be so simple; by the time
we are setting the
Update of bug #20513 (project make):
Triage Status:None = Verified
___
Reply to this item at:
http://savannah.gnu.org/bugs/?20513
___
Message
Follow-up Comment #6, bug #33129 (project make):
Sorry. It's a dup of bug #30723
___
Reply to this item at:
http://savannah.gnu.org/bugs/?33129
___
Message sent via/by Savannah
Follow-up Comment #3, bug #37208 (project make):
If you check the Fixed Release field for bug #30653 you'll see it says CVS,
which means it's fixed in the source but not in any release yet.
___
Reply to this item at:
Follow-up Comment #5, bug #37208 (project make):
Go up to the top of the Savannah bug page where it says Source Code, click
it, and choose the Use CVS link. It will tell you how to obtain the source
from CVS. Once you get the source you can look at README.cvs to see how to
build. Note you will
Update of bug #37315 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #1:
This actually is a
Update of bug #37307 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #37711 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Yes you must follow the
Update of bug #38051 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #37878 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #2:
This bug has already
Update of bug #37708 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
This is not technically
Update of bug #37703 (project make):
Triage Status:None = Need Info
___
Follow-up Comment #1:
I was not able to reproduce this situation, in either 3.82 or the current
latest codebase. You
Follow-up Comment #2, bug #38420 (project make):
Let me guess, you're working on Solaris? And probably using an NFS-mounted
filesystem? See, for example:
http://lists.gnu.org/archive/html/help-make/2006-04/msg00023.html
However, you're right that we should be doing a better job of error
Follow-up Comment #4, bug #38420 (project make):
The only option I can think of is using $(shell ...) to determine the real
path rather than the built-in realpath function. This will be slower, but
more reliable (as far as I'm aware all the EINTR issues with shell have long
since been solved).
Update of bug #38433 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
That's a valid
Update of bug #38437 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
This is how GNU make
Update of bug #38420 (project make):
Item Group:None = Bug
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:
Follow-up Comment #14, bug #30381 (project make):
I don't think it's correct to implement this feature using a command-line
option. Makefiles need to be written in a certain way to use this feature and
if they are written that way, then you must have the feature enabled or the
build will fail.
Update of bug #38442 (project make):
Triage Status:None = Need Info
___
Follow-up Comment #2:
I am not able to reproduce this with the current latest version from Git:
$ touch foo.vhd
$ make
Update of bug #37703 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #37970 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Operating System:
Update of bug #26893 (project make):
Triage Status:None = Need Info
___
Follow-up Comment #2:
If possible, please check if this issue is resolved by the fix for bug #37703.
Update of bug #37648 (project make):
Triage Status:None = Need Info
___
Reply to this item at:
http://savannah.gnu.org/bugs/?37648
___
Message
Update of bug #36397 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Follow-up Comment #9, bug #33138 (project make):
I'm looking at adding this feature this weekend, FYI.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?33138
___
Message sent via/by
Update of bug #33138 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Component Version:
Update of bug #38432 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #2:
I've applied the fix
Update of bug #38827 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
This is not a bug. By
Update of bug #2520 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
This bug seems to have
Update of bug #37065 (project make):
Triage Status: Need Info = None
___
Follow-up Comment #4:
Hi Eli; there's a makefile attached. It's maybe not everything we'd wish for
in a repro case but
Follow-up Comment #2, bug #2216 (project make):
I checked this. The problem only occurs with the -e flag, because by
specifying -e you're explicitly saying that the value from the environment
variable should supersede any value set in the makefile. GNU make is treating
this as true for the
Follow-up Comment #1, bug #26596 (project make):
Hm. I'm not sure why the immediate expansion has limited content. Is there
any purpose to this? Wouldn't it just be better to have the immediate
expansion resolve to the entire thing? I'll have to look into it; maybe
there's a good reason for
Update of bug #38945 (project make):
Triage Status:None = Need Info
___
Follow-up Comment #2:
I'm trying to create a repro case for this. I've created a file on Linux and
forced it to contain
Update of bug #39035 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Operating System:
Update of bug #39028 (project make):
Item Group:None = Enhancement
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:
1001 - 1100 of 2097 matches
Mail list logo
