Re: [3.81] Possible parallelizing bug in combination with multiple-target pattern rules

m&group=make and include all the details and the test case. Thanks! -boris -- Boris Kolpackov Code Synthesis Tools CC http://www.codesynthesis.com Open-Source, Cross-Platform C++ XML Data Binding ___ Bug-make mailing list Bug-make@gnu.org

[bug #18963] -include suppressing errors for too long?

Follow-up Comment #5, bug #18963 (project make): The last comment is about bug# 15110. Not sure if it is related to the original report. ___ Reply to this item at: _

Re: Auto deps problem with newest make

Hi Tadeusz, Tadeusz J Liszka <[EMAIL PROTECTED]> writes: > but when makefile contains > -include $(dep_files) > > makefile 3.81 simply exits I am pretty sure this is bug #15110: https://savannah.gnu.org/bugs/?15110 Previous make versions reported this error because they had a number of bugs in

[bug #20501] "MAKEFLAGS += -rR" doesn't turn off default suffix rules, variables

Follow-up Comment #6, bug #20501 (project make): Actually adding -r to MAKEFLAGS does work. It just that -p still prints the rules as if they were there. I use the following makefile fragment in our build system to get rid of all built-in (suffix and pattern) rules: # Remove all built-in rules.

[bug #24622] $$(eval) creating new targets causes segmentation fault

Follow-up Comment #2, bug #24622 (project make): IMO, adding new targets during the second expansion is conceptually wrong. Granted make shouldn't segfault, in this case we should just report an error, the same kind that make emits when seeing something like this: proj1.exe : proj1.o proj1.o : p

[bug #25140] Pattern-specific variable assignment behaves differently compared to normal variables

URL: Summary: Pattern-specific variable assignment behaves differently compared to normal variables Project: make Submitted by: bosk Submitted on: Sun 21 Dec 2008 10:20:54 AM GMT Seve

[bug #27047] Difficulties defining prerequisites for pattern targets.

Follow-up Comment #3, bug #27047 (project make): You can get the desired behavior using the second expansion feature (note $$): .SECONDEXPANSION: all:test1001.out foo: @echo making foo test1%.out: TEST=foo test%.out: $${TEST} @echo making test$*.out with TEST=${T

[bug #17752] target fails depending on order of prereqs

Follow-up Comment #6, bug #17752 (project make): I tend to agree, my change caused quite a few regressions according to the GNU make documentation. However, I also don't think the original 3.80 behavior is correct. That "ought to exist" is a misnomer. Who said that just because a file is made a p

[bug #27545] Patch to add Makefile.mak to default file names searched

Update of bug #27545 (project make): Severity: 3 - Normal => 1 - Wish Item Group:None => Enhancement ___ Follow-up Comment #1: If you refer to Micro

[bug #15110] Confusing failure message for generate dependencies with 3.81beta3

Update of bug #15110 (project make): Open/Closed:Open => Closed Component Version:None => 3.81 Fixed Release:None => CVS ___

[bug #15110] Confusing failure message for generate dependencies with 3.81beta3

Follow-up Comment #7, bug #15110 (project make): Fix is in CVS. ___ Reply to this item at: ___ Message sent via/by Savannah http://savannah.gnu.org/

[bug #15110] Confusing failure message for generate dependencies with 3.81beta3

Update of bug #15110 (project make): Status:None => Fixed ___ Reply to this item at: ___ Messa

[bug #12686] make quietly dies instead of issuing an error

Update of bug #12686 (project make): Status:None => Fixed Open/Closed:Open => Closed Component Version: CVS => 3.81 Fixed Release:

[bug #17740] make fails without any message

Update of bug #17740 (project make): Status:None => Fixed Assigned to:None => bosk Open/Closed:Open => Closed Fixed Release:

[bug #25780] .SECONDEXPANSION: of $$+ harmed by set_file_variables() side effect

Update of bug #25780 (project make): Status:None => Fixed Assigned to:None => bosk Open/Closed:Open => Closed Fixed Release:

[bug #28748] "matches" array is improperly sized in implicit.c:pattern_search()

Update of bug #28748 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => CVS

[bug #30370] add a shorthand syntax for foreach-eval-call

Follow-up Comment #5, bug #30370 (project make): I agree with Paul. The discussion on stackoverflow is talking about a more general mechanism, namely having pattern rules with multiple stems. I think if we were to consider such an extension, then it is better to go all the way and add support for

[bug #31002] make picks wrong pattern rule

Follow-up Comment #4, bug #31002 (project make): In this case GNU make 3.82 does exactly what it claims it will do. Unfortunately the expected (from glibc's perspective) behavior falls into that 0.01% of cases where the more qualified rule is not what needs to be selected. The assumption here is

[bug #31002] make picks wrong pattern rule

Follow-up Comment #6, bug #31002 (project make): Roland, I think you overstate the seriousness of the problem. There are not many makefiles that both define multiple pattern rules and rely on their order for selection. 3.82 has been out for a few months now and glibc is the first such case (which

Re: GNU make release candidate 3.99.90 available

e.g., Debian experimental). This will give you essentially free testing with a wide range of packages. Thanks, Boris -- Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog Compiler-based ORM system for C++ http://codes

Re: GNU make release candidate 3.99.90 available

ole thing if publicly available (see signature), it unfortunately won't build on Windows. Boris -- Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog Compiler-based ORM system for C++ http://codesynthesis.com/products/odb __

Re: GNU make release candidate 3.99.90 available

their case make runs on the user machine, not on the build server (where any regressions will be quickly detected and reported). Boris -- Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog Compiler-based ORM system for C++ http://codesynthesis.com/products/odb _

Re: GNU make 3.99.92 release candidate is available

Boris -- Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog Compiler-based ORM system for C++ http://codesynthesis.com/products/odb ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make

Re: GNU make 3.99.92 release candidate is available

y-intensive processing (entering files into caches, creating all the dependency structures, pattern matching, etc). It could be some bad CPU cache interaction. That was my first thought since everything on this machine is faster, CPU, disks, memory. Boris -- Boris Kolpackov, Code Synthesish

[bugs #7310] comments are not ignored in $(call) /$(eval)

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=7310> Project: make Submitted by: Boris Kolpackov On: Sun 01/18/04 at 05:36 Severity: 5 - Average Item Group: Bug Resolution: None Assigned to: None Status: Open Component Version: CVS Platform Version: Any Fixed Rele

creation of a directory

Good day, I was wondering if there is a valid reason for the following makefile not to work. hello : | foo/ hello : @echo hello %/ : mkdir $* thanks, -boris signature.asc Description: Digital signature ___ Bug-make mailing list [EMA

Re: creation of a directory

Hi Paul, > GNU make strips trailing slashes, so that "foo/" and "foo" are > considered the same prerequisite. Is it because make just does it this way or there is some deep reason for that? For example, $(dir) does not strip the trailing slash. Oh, but $(@D) does... > You can get your makefile

Re: creation of a directory

Hi Paul, > It's done so that if you write: > > foo: bar/ > > in one place in your makefile, and: > > bar: biz > > another place, and: > > boz: $(CURDIR)/bar > > in a third place, make realizes they are all the same target and won't > try to build them multiple times (or, say "do

Re: creation of a directory

Hi Noel, > Since there is a workaround, simplifying GNU make in this respect > isn't worth it. Speaking of workaround, having the following implicit rule %/. : @mkdir $* you cannot just write foo : bar/ instead you will have to write foo : bar/. which is quite ugly and unnatural.

-include

Good day, I found a somewhat surprising behavior of -include. Consider the following makefile: bar: foo := baz -include bar hello: @echo hello I would expect it to print 'hello'. Instead make complains that it cannot build 'bar'. Here is what happens. The first line of this makefile

Re: -include

Good day, Just want to follow up with another bug from the same area. Consider the following makefile: -include bar hello: @echo hello bar : foo cp foo bar Make fails even though the manual says that it will not: " If you want `make' to simply ignore a makefile which does n

double-colon logic for normal rules

Good day, In remake.c (cvs version) in function update_file there is a fragment of code which presumably is intended for double-colon rules only (line 324-332): /* Process the remaining rules in the double colon chain so they're marked considered. Start their prerequisites, too. */ fo

[PATCH] pattern-specific variable expansion

Good day, The following makefile prints 'B' instead of 'A'. a := A %bar : arg := $a %bar : ; @echo $(arg) a := B foobar: Patch is attached for those who find this behavior surprising. Also note that this patch does not address the following cases: %bar : a := a %bar : $a_b := a_b # doesn

Re: wish: multiple target patterns in a static pattern rule

Ted Stern <[EMAIL PROTECTED]> writes: > You can reduce potential compilation cascades even further by > ensuring that your *.gob processor compares previously existing > output files against the new output and retains the original > timestamp if no changes have been made. This is a good examp

define strangeness

Good day, Well, Paul will probably tell me that it is not a bug (as he did with comments in define) but I will report it anyway. Consider this makefile: foobar := world define name \ foobar endef .PHONY: hello hello: ; @echo hello $(value $(name)) It prints just "hello". I would guess it is b

Re: define strangeness

Paul D. Smith <[EMAIL PROTECTED]> writes: > bk> Consider this makefile: > > bk> foobar := world > > bk> define name > bk> \ > bk> foobar > bk> endef > > bk> .PHONY: hello > bk> hello: ; @echo hello $(value $(name)) > > bk> It prints just "hello". I would guess it is because

[PATCH] order-only prerequisite ends up in $

Good day, The following makefile prints "baz foo baz" instead of "foo foo baz". %r: | baz @echo $< $^ $| bar: foo foo:;@: baz:;@: In command.c in function set_file_variables $< is initialized with the first prerequisite. While in most cases this would be a normal prerequisite in ca

Re: [PATCH] pattern-specific variable expansion

Noel Yap <[EMAIL PROTECTED]> writes: > Hmmm, I ran into something similar in which: > > a := A > > bar: > @echo $a > > a := B > > > would output B. This is correct behavior as per manual. If you want it to print A then write something like bar: a_ := $a # not sure a := $a will

Re: [PATCH] order-only prerequisite ends up in $

Noel Yap <[EMAIL PROTECTED]> writes: > Once this patch is installed, does "gmake -npqr | grep '%r:'" output the > proper thing? If so, I suspect this patch will fix much of the odd > behaviour I've seen with regards to implicit rules and order rules. Well, it depends what is "proper thing"? Wi

Re: [PATCH] pattern-specific variable expansion

Paul D. Smith <[EMAIL PROTECTED]> writes: > bk> In contrast the patch fixes the following case: > > bk> a := A > > bk> %bar : a_ := $a > > bk> %bar :; @echo $(a_) > > bk> a := B > > bk> foobar: > > bk> Which prints (without patch) B. > > I want to point out that I think we

Re: define strangeness

I see you are running make time-slice ;-) Paul D. Smith <[EMAIL PROTECTED]> writes: > bk> No, I think it should handle newline-backslash sequence the same > bk> way everywhere, including inside "define". > > Hm. But, make already doesn't handle backslash/newline the same way > everywhere;

Re: Is this a bug in GNU make 3.80?

DervishD <[EMAIL PROTECTED]> writes: > Just one more point: is there any way to force the -R or -r flags > then? Not that it is essential, but... I am not sure about 3.80 but in 3.81beta1 I believe saying .SUFFIXES: MAKEFLAGS += -r is 'logically' equivalent to saying 'make -r'. If you want

[RFC] .NOT_DEFAULT: target

Good day, I came to the point where I cannot work around "default target hijacking" problem. So I am planning to do something about it in my -bk patch-set. I also hope this feature will end up in the main stream thus this RFC. When makefile inclusion is used there is a recurring problem of defau

Re: [RFC] .NOT_DEFAULT: target

Paul D. Smith <[EMAIL PROTECTED]> writes: > The way I typically solve this is that I always define the target I want > to be the default first, with no prerequisites etc. Simply putting > something like: > > all: > > by itself at the top of the first makefile is enough to force make to > c

Re: need access to Makefile path

Dave Yost <[EMAIL PROTECTED]> writes: > Consider a Makefile that starts thus: > > include ../../../Makefile-master > > It would be nice if this included Makefile-master knew where it was, $(dir $(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST))) -boris ___

Re: need access to Makefile path

Noel Yap <[EMAIL PROTECTED]> writes: > Try: > > $ cat >bar.make > include foo.make > $(warning $(dir $(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST You gotta be kidding me! p := $(dir $(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST))) include foo.make $(warning $p) signature.asc Descr

Re: need access to Makefile path

Noel Yap <[EMAIL PROTECTED]> writes: > Although it's reminiscent of DOS, I like your use of '%' in private > variable names. They are called "system variables". > One thing I can say right now is, if you had an include-makefile function, > the below would become: > > $(call include-ma

Re: need access to Makefile path

Noel Yap <[EMAIL PROTECTED]> writes: > How are you going to guarantee that the names of the variables are unique? You could use variable framing ;-) > Do you still think that MAKEFILE_LIST is a scalable, viable solution? It is good enough to bootstrap and build on top. -boris signature.a

Re: need access to Makefile path

Noel Yap <[EMAIL PROTECTED]> writes: > Unless MAKEFILE_LIST is used before any other includes, using the trick > below doesn't work. $ cat >makefile include foo.make include $(CURDIR)/bar.make $ cat >foo.make $ cat >bar.make $(warning $(dir $(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST

Re: need access to Makefile path

Noel Yap <[EMAIL PROTECTED]> writes: > >>How are you going to guarantee that the names of the variables are unique? > > > >You could use variable framing ;-) > > What's variable framing? You can say $(call frame-enter) include foo.make $(call frame-leave) and any changes to variables inside

Re: [PATCH] .NOT_DEFAULT: target

Paul D. Smith <[EMAIL PROTECTED]> writes: > Mm. I don't know about this. BTW, the changes are just a few lines and in one place! ;-) -boris --- make-cvs-orig/read.c2004-05-16 19:19:57.0 -0500 +++ cvs-bk4/read.c 2004-05-19 14:59:18.0 -0500 @@ -2140,6 +2140,22 @@

Re: failing "make install" because missing lib

Julien Michielsen <[EMAIL PROTECTED]> writes: > Trying to compile and install gphoto, I can't succeed to run "make" > as it cannot find libslang.so.1 (which lives in /usr/lib) . I ran > configure with libdir=/usr/lib, but still make ends with > "cannot find -lslang". At one point I got "make" run

Re: Bug in make...

santhosh km <[EMAIL PROTECTED]> writes: > x: > ccsimpc -o HELLO_WORLD helloWorld.o ^^ ___ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/

bugs fixed in -bk4

Hi Paul, I have one patch in my -bk patch-set which, IMO, has no reason of not being in the main trunk. It implements dontcare flag inheritance which, combined with your recent changes to the dontcare machinery, fixes both bugs described here http://mail.gnu.org/archive/html/bug-make/2004-02/m

Re: bugs fixed in -bk4

Sam Ravnborg <[EMAIL PROTECTED]> writes: > >From info make: > > > Rule Definition > --- > >A rule is always expanded the same way, regardless of the form: > > IMMEDIATE : IMMEDIATE ; DEFERRED > DEFERRED > >That is, the target and prerequisite se

Re: target-specific 'define'd variables (3.80)?

"Paul D. Smith" <[EMAIL PROTECTED]> writes: > %% Will Partain <[EMAIL PROTECTED]> writes: > > wp> Hi; I don't know if the little Makefile below *ought* to > wp> work or not; it seems it should. > > No. define/endef is not supported directly in kernel-specific > variables. The entire defini

Re: target-specific 'define'd variables (3.80)?

Paul D. Smith <[EMAIL PROTECTED]> writes: > I don't see any reason technically that it couldn't be done. That's what I thought too. Also it would be nice to extend the concept of target/pattern-specificity to other parts of make, e.g.: /foo/bar: foo := hello foo := $(/foo/bar: foo) #

Re: target-specific 'define'd variables (3.80)?

Paul D. Smith <[EMAIL PROTECTED]> writes: > It's not really clear to me when it's that useful to query, at a > _GLOBAL_ scope like this, what target-specific variables are set for a > given target. This will allow (theoretically) hierarchical namespaces, e.g., .PHONY: /a% /a/b% /a%: foo := F

Re: Problem with absolute path

Juergen Schmidt <[EMAIL PROTECTED]> writes: > has anybody an idea on this or can help me? I am not sure this will actually help you but here it goes. GNU make makes some strange guesses (see make.c around line 99) when it comes to files in directories that do not exist. Consider for example th

Re: Problem with absolute path

Paul D. Smith <[EMAIL PROTECTED]> writes: > Anyway, the idea was certainly performance: if a directory doesn't exist > and there are no rules in your makefile to create it (that is, there are > no targets that allow make to create that directory), then in make's > model it can never exist, so re

Re: better symlink handling

"Paul D. Smith" <[EMAIL PROTECTED]> writes: > There are a number of suggestions already available in the bugs and > patches sections of GNU make's Savannah project. Something will appear > in the next version of GNU make. Isn't it just an instance of a general problem of custom out-dateness? Wou

Re: implicit rule invocation issue

"Hakenson, Gary C." <[EMAIL PROTECTED]> writes: > Do you have any suggestions as to how this may be accomplished? When you say VPATH = /d you are in some sense asking make to add directory /d to the make's current directory. When you say %.d : %.c ... you are in some sense asking

Re: target variable expansion with included make files

"Brad Kemp" <[EMAIL PROTECTED]> writes: > The main makefile includes two small makefiles. > Each make file defines variables used in the targets of the other makefile. > The target names are immediatly expanded which causes the first makefile > not to use the variables defined in the second makefi

Re: target variable expansion with included make files

"Brad Kemp" <[EMAIL PROTECTED]> writes: > What I am trying to do is to build a project out of many sub projects. > As each sub project is updated, I want the final target pathname to reflect > the new revision level without having to change the main makefile. > This allows me to build multiple ver

Re: fatal errors for missing include files.

"Paul D. Smith" <[EMAIL PROTECTED]> writes: > id> Ok, but I am surprised you don't you see any problem (bug) with > id> the current way? > > Not really. The times where it makes any difference are very few, I don't think the presence of the bug is in any way affected by the number of situat

Re: fatal errors for missing include files.

Paul D. Smith <[EMAIL PROTECTED]> writes: > If it is a bug then what you say is true, but I have never termed it a > bug. It was a design decision taken between two alternative > implementations, and the code is operating the way it was designed and > intended to work. I don't believe you ever

Re: incorrect error message

Bruno Haible <[EMAIL PROTECTED]> writes: > To reproduce: In an otherwise empty directory, create this Makefile: > > > %.erg : ../bar > echo done > > %.erw : ../baz > echo done > > foo.res : ../baz > echo done > =

Re: incorrect error message

Boris Kolpackov <[EMAIL PROTECTED]> writes: > Also assume that there is a file `baz' in current directory. That should be `bar', of course. ___ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make

Re: incorrect error message

Paul D. Smith <[EMAIL PROTECTED]> writes: > This sounds familiar to me: pls. send it. Thx. Patch and test makefile are attached. -boris diff -u -b -B --minimal make-cvs-orig/file.c make-cvs-patched/file.c --- make-cvs-orig/file.c2004-05-16 19:19:57.0 -0500 +++ make-cvs-patched/

Re: Order-only dependencies don't work

"Daniel Olivier" <[EMAIL PROTECTED]> writes: > It builds fine the first time, but for some reason. If I attempt to make a > second time, because the obj_dir directory (dependency) is newer than the > (target) obj1.o, the rule is re-run, causing the "compiler" (touch in this > simplified case) and

Re: Can't build from cvs sources

Robert Mecklenburg <[EMAIL PROTECTED]> writes: > "Well, bust my buttons!" After creating an empty build.sh.in > autoreconf succeeded in building a configure script. Even running the > ./configure script seemed to "work". But then, running make failed: Did you say `make update' as prescribed in

Re: eval function within 'ifeq... else... endif' causes error

François Duranleau <[EMAIL PROTECTED]> writes: > And then, running make with the above produces: > > % make > Makefile:20: *** missing `endif'. Stop. This works as expected with make from cvs. -boris ___ Bug-make mailing list Bug-make@gnu.org http:

Re: whitespaces in filenames [was: bug in $(wildcard) on Windows?]

"Paul D. Smith" <[EMAIL PROTECTED]> writes: > * A new method for encoding strings would need to be found. Maybe > something like $[...] where "..." would be encoded. This part is > tricky and needs to be considered carefully. Is this really necessary? Can't we just say that if someone

Re: make handling of prerequisites that interlock?

Ben Pfaff <[EMAIL PROTECTED]> writes: > Prerequisite `c' is newer than target `a'. < 1 > Prerequisite `b' is newer than target `a'. < 2 > No need to remake target `a'. < 3 I simplified your makefile a bit: a: b cat $^ >$@ b: x cat $^

Re: make handling of prerequisites that interlock?

Boris Kolpackov <[EMAIL PROTECTED]> writes: > cat x >b# timestamp(b) = 1 > cat b >a# timestamp(a) = 2 > echo x >x # timestamp(x) = 2 > cat x >b# timestamp(b) = 2 > > > The code in GNU make that decides whether to print "Prerequisite `c&#

Re: functions/realpath test failure on AIX

Albert Chin <[EMAIL PROTECTED]> writes: > On AIX 4.3.3, 5.1, and 5.2, $(realpath .///) appends "/": > $ cat /tmp/a > .PHONY: all > all: > @echo $(CURDIR) > @echo $(realpath .///) > $ ./make -f /tmp/a > /opt/build/make-3.81beta3/tests > /opt/build/make-3.81beta3/tests/ Does

Re: How to add comma to a list?

Ted Stern <[EMAIL PROTECTED]> writes: > Hi all, Your post belongs to help-make, not bug-make. > > What is the proper way to insert commas into each word of a GNU Make > variable? > > I want to change FOO something like this: > > FOO := a b c d e > FOO := $(patsubst %,-Wl,-y,%_,$(FOO))

Re: Bug in builtin function abspath

Andreas, Andreas Buening <[EMAIL PROTECTED]> writes: > The builtin function abspath does not consider drive letters. > Therefore, I think it will break not only on OS/2 but also on DOS > or Win* systems. And I suspect it won't work on VMS, too. I think you are correct. I implemented abspath and

Re: [bug #13976] Regression in :: deps handling between V3.76 and V3.80

"Paul D. Smith" <[EMAIL PROTECTED]> writes: > rm> I'll admit that the processing of :: targets is a gray area, and > rm> the .WAIT approach is the clearest solution. > > Well, clear_ER_ anyway. There was a discussion on the idea of .WAIT some time ago on the help-make mailing list (Subject: "

Re: [bug #13976] Regression in :: deps handling between V3.76 and V3.80

Paul, Sorry, it took me a while to reply. My comments are below. Paul D. Smith <[EMAIL PROTECTED]> writes: > The rules I mentioned in this list apply only between the two > prerequisites listed, in that pathway. If the "waited for" prerequisite > appears on any other path where it is not waited

Re: [bug #13976] Regression in :: deps handling between V3.76 and V3.80

Paul, Paul D. Smith <[EMAIL PROTECTED]> writes: > I disagree, actually. It's a settled feature of make that the DAG is > not a simple tree: that there can be more than one pathway to a given > target in the DAG. > > The placement of the .WAIT prerequisite implies a relationship between > two pre

Re: 3.81beta3 build error on HP-UX 10.20

Peter, Peter Fales <[EMAIL PROTECTED]> writes: > So far, so good. However, signame.c contains: > > #if !defined(HAVE_DECL_SYS_SIGLIST) > > Since HAVE_DECL_SYS_SIGLIST is defined (but with value 0), the code > is skipped even though it's needed on this platform. This already have been fixed in

[bug #15584] 3.81.b4 much slower than 3.80 in some situations

Follow-up Comment #10, bug #15584 (project make): So I did some mode digging and it appears that make just does what it's supposed to do. If you look into this makefile carefully you will see the pattern rule that looks like this %.hi: %.o which pretty much makes every single .o file depend (dire

[bug #15584] 3.81.b4 much slower than 3.80 in some situations

Follow-up Comment #12, bug #15584 (project make): It appears that 3.80 has a bug in handling of .SECONDARY. It does not actually mark individual targets as intermedite. As a result, check_dep doesn't treat any target in this makefile as intermediate. In CVS the following code was added in file.c

[bug #15584] 3.81 does way too much work in some pathalogical situations.

Update of bug #15584 (project make): Assigned to:bosk => None ___ Reply to this item at: ___

Re: Make-3.81 rc1 hangs with -j 2 (multiplatform)

"J. David Bryan" <[EMAIL PROTECTED]> writes: > I originally reported a make-3.81rc1 hang against the Windows port here: > > http://lists.gnu.org/archive/html/make-w32/2006-02/msg00058.html I did some digging and here is what I uncovered: 1. If I remove test.2 from .SECONDARY, make does not ha

Re: Make-3.81 rc1 hangs with -j 2 (multiplatform)

David, J. David Bryan <[EMAIL PROTECTED]> writes: > On 27 Feb 2006 at 13:09, Paul D. Smith wrote: > > > %% Boris Kolpackov <[EMAIL PROTECTED]> writes: > > > > bk> 3. If I replace the "%.3 : | %.2" rule with the equivalent normal >

[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1

Follow-up Comment #1, bug #15919 (project make): > This one looks like it's going to be a big PITA to fix. Do you have any thoughts on why it hangs when we use the implicit rule and does not when we use a normal one. After instantiation of the implicit rule, the two cases should be equivalent.

[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1

Follow-up Comment #3, bug #15919 (project make): After some more testing, it appears that removing test.3 from .SECONDARY prevents make from hanging, not test.2. ___ Reply to this item at:

[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1

Follow-up Comment #4, bug #15919 (project make): I tried to minimize the makefile but couldn't get any rules out without removing buggy behavior. I could get .SECONDARY out of the way, however. The first line in the makefile: .SECONDARY: test.1 test.2 test.3 Can be replaced with .INTERMEDIATE:

[bug #16051] Non-existent prerequisites are not included in $?

Follow-up Comment #1, bug #16051 (project make): Wouldn't it be better to (temporarily) add a special target that triggers the correct behavior? It seems kind of backward to deprive people of a bug fix just because some influential project has a buggy build system. _

[bug #16053] second stem overwrites the first per-prerequisite stem

Follow-up Comment #1, bug #16053 (project make): Attaching a minimized test case. It prints "all.foo.one all.foo.two" while should print "all.one all.foo.two". I also checked the code and it seems that keeping stem in prerequisites is the best way to solve this. I am not sure, however, if we sho

[bug #16053] second stem overwrites the first per-prerequisite stem

Update of bug #16053 (project make): Assigned to:None => bosk ___ Follow-up Comment #3: I would rather fix it properly right away than to come back to it. Will try to fix it before the e

[bug #16053] second stem overwrites the first per-prerequisite stem

Update of bug #16053 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => CVS

[bug #16140] make 3.81rc2: performance decrease when searching builtin implicit rules compared to 3.80

Update of bug #16140 (project make): Assigned to:None => bosk ___ Follow-up Comment #1: I took a quick look and it appears that we call set_file_variables even if none of the dependencie

[bug #16145] .SECONDARY: prevents non-existent dependency from forcing rebuild

Follow-up Comment #1, bug #16145 (project make): I believe this is intended behavior as described in GNU make manual. See bug #15584 (starting from comment #6) for more information. In your case *all* targets are SECONDARY. The reason it worked differently in 3.80 is because this version does no

[bug #16140] make 3.81rc2: performance decrease when searching builtin implicit rules compared to 3.80

Update of bug #16140 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => CVS

Re: make 3.81 test failure

Paul, [EMAIL PROTECTED] (Paul Jarc) writes: > + work/variables/INCLUDE_DIRS.mk:3: .INCLUDE_DIRS is empty This is probably because you built make with install prefix (--prefix) being a non-existent directory. Can you reconfigure make with something like --prefix /usr/local and see if this test st

[bug #16531] Substitution reference and secondary expansion

Follow-up Comment #1, bug #16531 (project make): GNU make gets confused by the % in your patsubst call. You will need to add an indirection: .PHONY: foo.bar .SECONDEXPANSION: p := % foo: $$(patsubst $p,$p.bar,$$@); @echo $^ ___ Reply to

Re: Bug in builtin function abspath (again)

Eli Zaretskii <[EMAIL PROTECTED]> writes: > > > The realpath function will resolve both absolute and relative paths > > > and return the absolute pathname corresponding to pathname. All but > > > the last component of pathname must exist when realpath is called. I just checked the page for realpa

  1   2   >