Update of bug #16051 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
On Sunday, 6 August, Ralf Wildenhues ([EMAIL PROTECTED]) wrote:
I noticed a couple of typos in the make manual.
I installed fixes for these. Thanks!
--
---
Paul D. Smith [EMAIL PROTECTED] Find some GNU make
Follow-up Comment #3, bug #17740 (project make):
Someone who sees this problem will need to either provide a reproducible test
case, or a description clear enough to allow me to create one. Based on the
information in this bug I tried this:
include foo.d
foo.d: foo.x ; : cp $ $@
all: ; :
Update of bug #18116 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #2:
As Philip says, the
Follow-up Comment #2, bug #18139 (project make):
It's not true that this is a Windows-only thing. I reproduced it on my Linux
system.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?18139
Follow-up Comment #5, bug #18139 (project make):
Boris, I don't see why %.o being intermediate makes a difference. Make can
and does chain implicit rules. I re-read the section on chaining and I don't
see anything that would contradict the basic premise of chaining, which is
that the length of
Follow-up Comment #2, bug #18124 (project make):
FYI, there's some conversation on this bug over in the Red Hat Bugzilla
database. I don't understand the bug and the patch doesn't enlighten me, so
I'm asking for some more detail.
___
Follow-up Comment #8, bug #18139 (project make):
Hm. Boris, is that the way it's always worked or is it something we changed
recently? According to the docs as far as I can tell there's no such
distinction between rules that require intermediates and those that don't.
In fact, it seems pretty
Follow-up Comment #10, bug #15919 (project make):
Hi Icarus. The easiest way to get a patch into GNU make is to attach it to
the bug report and/or create a separate patch item (the first is preferred).
We'll review it and apply it as-is or else discuss it with you if necessary.
Also, if the
Update of bug #18173 (project make):
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Heh. Cute :-)
Feel free to use some other software to do your builds. We won't be
offended. We
Follow-up Comment #12, bug #15919 (project make):
Thanks Icarus; that's great. Especially new testcases: that always helps.
One thing: in general I like to have the ChangeLog entry describe what the
change does and how it fixes things, rather than just describing the symptoms
of the bug. Do
Update of bug #18312 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #1:
This bug was already
Follow-up Comment #2, bug #17881 (project make):
Actually, make _does_ guarantee that rules will be processed in left-to-right
order. If you never use parallelism, you can be sure your rules will always
run in that order.
If you do use parallelism, though, obviously more than one of these
Update of bug #18369 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #1:
The short answer is,
Update of bug #18396 (project make):
Item Group: Bug = Enhancement
___
Follow-up Comment #1:
If 'make' needs to allocate a large amount (megabytes) of data,
it would be better to do so on
Follow-up Comment #2, bug #18396 (project make):
I wrote:
if large amounts of memory are needed they are allocated on the stack
Of course I meant on the _heap_ :-/.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?18396
Update of bug #18517 (project make):
Status:None = Later
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Hi all.
The make
Update of bug #18680 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #18872 (project make):
Status:None = Fixed
Open/Closed:Open = Closed
Component Version:None = 3.81
Fixed Release:
Update of bug #18561 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
It is by design; in
Update of bug #18641 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #2:
I understand that this
Follow-up Comment #4, bug #18641 (project make):
The method for auto-generating dependencies described in the GNU make manual
is not the state-of-the-art method. You should check my website
http://make.paulandlesley.org and look at the advanced auto-dependency
generation description there.
Update of bug #18963 (project make):
Item Group: Bug = Documentation
___
Follow-up Comment #3:
I can see that the documentation is not clear enough. Perhaps it is trying
to be too stylized, to
Update of bug #19015 (project make):
Status:None = Works for me
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Sorry, but this is not
Update of bug #18995 (project make):
Item Group:None = Enhancement
Operating System:None = Any
___
Follow-up Comment #1:
Internally to make, an
Follow-up Comment #1, bug #19035 (project make):
Sorry, but there's nothing we can do unless you provide more details, such as
a small example of a makefile that does not work properly for you.
Note that Solaris and HP contain SystemV make; GNU make is not intended to be
a 100% compatible
Update of bug #19183 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
This is not a bug.
Update of bug #19236 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
I agree this is
Update of bug #19309 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #2:
This is not a bug, and
Update of bug #19626 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
This is the way make
Follow-up Comment #2, bug #16389 (project make):
I don't really understand the urgency around this: why not just add the rules
into your makefile if you need them? The built-in rules are just that:
built-in; they can be added to or removed in makefiles.
I do realize this means that any
Follow-up Comment #1, bug #19656 (project make):
Can you please provide the error messages you received? As far as I know GNU
make sources don't use strcmpi() except when compiling for non-POSIX systems.
___
Reply to this item at:
Follow-up Comment #3, bug #19448 (project make):
Sorry, but you're incorrect about the way original UNIX make worked. In
fact, every version of make that I'm familiar with does and has always
considered equal timestamps as up to date. The POSIX standard for make is
quite clear about this as
Follow-up Comment #6, bug #19448 (project make):
In fact, your original idea of passing -W foo for each included file foo
so that the re-invoked make would realize it should not be built again WAS
implemented (by me) in an earlier version of GNU make.
However, it lasted only a few days out in
Update of bug #19035 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #18617 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Operating System:
Update of bug #19900 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #3:
Closed.
Follow-up Comment #2, bug #19975 (project make):
Note that GNU make has received a Google Summer of Code project, to implement
the ability for users to customize the out of date algorithm used by make.
You might consider waiting a couple of months and see what comes of that by
the end of the
Update of bug #20033 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #20067 (project make):
Item Group: Bug = Enhancement
___
Reply to this item at:
http://savannah.gnu.org/bugs/?20067
___
Message
Update of bug #20018 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Follow-up Comment #1, bug #20133 (project make):
I looked at this briefly and it's tough. In order to get the proper behavior
for the target-specific variables, make has to modify the way the variable is
stored; once that happens it's pretty hard to reconstruct the way the
variable originally
Follow-up Comment #2, bug #20394 (project make):
It's not exactly correct to say that GNU make caches directories from the
10th on, but you're on exactly the right track; thanks for the note.
What make actually does is cache EVERY directory... BUT it caches them
lazily, AND it only allows 10
Follow-up Comment #4, bug #20394 (project make):
Something like that could be tricky to accomplish, since make is highly
recursive: when make starts checking for timestamps on files it doesn't know
whether that file was found using implicit or explicit rules, etc.
Plus, I think it would be even
Follow-up Comment #20, bug #15919 (project make):
OK, I went through both this bug and bug 3330 last night, and I do see the
problem; thanks for all your work and the patch you provided Icarus.
However, I'm not entirely sure that the way you solved this problem is the
best one. Setting the
Follow-up Comment #6, bug #20394 (project make):
I haven't looked into it carefully, but it's not immediately clear to me that
it's a simple thing to avoid the directory cache for chained/intermediate
rules, vs. any other kind of rule.
The disadvantage with the is_stale boolean is that every
Update of bug #20452 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
trying to build.
--
---
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 #15919 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #3330 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #20995 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
Summary: \ along multiple lines lines for '...' doesn't work
= along multiple lines
Update of bug #21376 (project make):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #1:
This is a duplicate of
Follow-up Comment #5, bug #21661 (project make):
Ah, now it's clear what the confusion is. This happens because make puts
command line variable settings into the environment to be exported to the
subshell. And, of course, before make can invoke a subshell it has to expand
all the variables
Update of bug #22198 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Reply to this item at:
Follow-up Comment #2, bug #22379 (project make):
No, that Debian bug is different (and that whole section of code is different
in the next release of GNU make, so it's no longer needed).
Please try the attached patch and see if it works.
(file #15253)
Update of bug #22379 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Follow-up Comment #1, bug #22442 (project make):
I'm not sure your reading of POSIX is correct. It says:
-
Inference rules can be redefined. A target that matches an existing inference
rule shall overwrite the old inference rule. An empty rule can be created with
a command consisting of
Update of bug #21716 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #23793 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
I don't believe this
Update of bug #24164 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #3:
The followup comments
Update of bug #24486 (project make):
Severity: 3 - Normal = 1 - Wish
___
Follow-up Comment #1:
There is no good way to do this without completely rearchitecting how GNU
make works.
See:
Update of bug #24522 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
The $(info) function
Follow-up Comment #2, bug #24723 (project make):
Make can already do this with pattern rules. I'm assuming you mean with
explicit rules?
___
Reply to this item at:
http://savannah.gnu.org/bugs/?24723
Update of bug #25140 (project make):
Item Group: Bug = Enhancement
___
Follow-up Comment #1:
The reason this happens is because pattern-specific variables are treated
very differently from
Update of bug #25190 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #2:
This is not a bug.
Update of bug #25578 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
The problem is you
Follow-up Comment #2, bug #25578 (project make):
Hm. The markup seems to have swallowed my should be section. Also, the
email seems to have deleted ALL the backslashes. Anyway, you get the idea.
___
Reply to this item at:
Update of bug #20495 (project make):
Status:None = Fixed
Assigned to:None = eliz
Open/Closed:Open = Closed
Fixed Release:
Update of bug #25844 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Hi; note that
Follow-up Comment #5, bug #26075 (project make):
Hm, that's interesting. There's no doubt that the directory cache causes
unexpected consequences when your makefile does things behind the scenes
that make doesn't know about (so it can't update the cache appropriately).
However, this is the
Update of bug #26207 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #25460 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #25694 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #25697 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Follow-up Comment #3, bug #26307 (project make):
Well, I surely don't know.
GNU make is a tool used to control compiling programs. It has absolutely
nothing to do with Firefox, Gnash, Red Hat, swfdec or any other codec, or
anything else related even remotely to the problem you're having as far
Follow-up Comment #2, bug #24588 (project make):
See also duplicate bug #24622 for another example.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?24588
___
Message sent via/by
Update of bug #24488 (project make):
Item Group: Bug = Enhancement
___
Follow-up Comment #1:
I'm not convinced that this request is something we actually want to
implement; .PHONY is not only
Update of bug #23986 (project make):
Status:None = Works for me
Open/Closed:Open = Closed
___
Follow-up Comment #1:
You need to get the
Update of bug #24277 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #24251 (project make):
Privacy: Private = Public
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #24488 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Reply to this item at:
Follow-up Comment #1, bug #16670 (project make):
OK, the fix for this is simple enough. However, it does cause user-visible
changes. It's not so much the replacing of each backslash/newline/following
whitespace with a space that's the issue, it's the fact that TRAILING
whitespace on the
Follow-up Comment #2, bug #16670 (project make):
Ugh. Savannah's comments kind of suck. I mean, the current behavior gives:
a b
and the POSIXly-correct behavior would give:
a b
___
Reply to this item at:
Update of bug #26593 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #24588 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #24655 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #25712 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #15919 (project make):
Status: Fixed = None
Open/Closed: Closed = Open
___
Follow-up Comment #28:
I've been running the
Follow-up Comment #29, bug #15919 (project make):
I took a copy of glibc 2.9 and tried building it with -j10 on my uniprocessor
and on my dual core (actually single hyperthreading CPU) and it worked fine.
But when I took it to a 4-way hyperthreading (8 core) system and ran with
-j10 I did see
Update of bug #15919 (project make):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #30:
I debugged this and
Update of bug #25703 (project make):
Item Group: Bug = Enhancement
___
Follow-up Comment #1:
I'm marking this as an enhancement, since the code works as designed. I
agree it would be nice to
Update of bug #22010 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #22434 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #6:
This problem is
Update of bug #22442 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Closing. Feel free to
Update of bug #23361 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Dave's comment is
Update of bug #23210 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #3:
The problem is that
Update of bug #21854 (project make):
Status:None = Fixed
Open/Closed:Open = Closed
Fixed Release:None = CVS
Update of bug #21823 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Update of bug #21198 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Component Version:
Update of bug #24622 (project make):
Status: Duplicate = Fixed
Assigned to:None = psmith
Fixed Release:None = CVS
701 - 800 of 2090 matches
Mail list logo
