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

[anonymous]

URL:
  

 Summary: -include suppressing errors for too long?
 Project: make
Submitted by: None
Submitted on: Montag 05.02.2007 um 16:15 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: POSIX-Based
   Fixed Release: None

___

Details:

with these 2 files:

Content of Makefile:
all: file.o

%.d:
touch $@
exit 127

%.h:
@echo "File '$@' does not exist."
exit 128

-include file.d


Content of file.d:
file.o file.d: file.h

I only get:
# gmake
File 'file.h' does not exist.
exit 128
#

but no error exit code. Strictly this could also be a documentation bug,
because there it talks about "does not exist _AND_ cannot be remade" for
-include. Maybe the AND should be changed to OR. In that case please consider
this as an enhancement request for a variation of the -include directive,
which will return an error in this case.

Thanks,
Franz.





___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

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

[anonymous]

Follow-up Comment #2, bug #18963 (project make):

I'm aware that -include is supposed to produce no error if file.d does not
exist. But in my case file.d exists, it's just that the header file.h is not
there and cannot be remade. AFAICS nowhere in the manual it is mentioned that
also the errors _IN_ an _EXISTING_ makefile fragment are suppressed with
-include.

Franz.


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #19015] Initialisation of variable to "ls" and "find" fails with "**missing separator"

[anonymous]

URL:
  

 Summary: Initialisation of variable to "ls" and "find" fails
with "**missing separator"
 Project: make
Submitted by: None
Submitted on: Friday 02/09/2007 at 23:53 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: Any
   Fixed Release: None

___

Details:

Any attempts to initialize the global variables
LS = ls
FIND = find
failed with error message "*** missing separator. stop". All other commands
like "grep", "rm", "mkdir" and others work.
I tried use the declaration with whole path i.e. LS = /bin/ls it did not help
either.






___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #19113] cannot self-remake makefile starting with './'

[anonymous]

URL:
  

 Summary: cannot self-remake makefile starting with './'
 Project: make
Submitted by: None
Submitted on: Tuesday 02/20/2007 at 20:39 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: POSIX-Based
   Fixed Release: None

___

Details:

for a makefile foo (see attached), the makefile will not be updated before
being run if prefixed with a ./

To duplicate:
 * run the attached foo script from the current directory using "./foo"
 * or run "make -f ./foo"

To see the expected behavior:
 * run "make -f foo"

this was discovered when trying to make a self-executing makefile which
starts with "#!/usr/bin/make -f"

This also happens (not unexpectedly) when running "make -f ./foo"

The bug does not occur, however, when running "make -f foo" (without the
preceding ./)

The bug does also not apply to included makefiles, whether prefixed with ./
or not. All included makefiles appear to be updating correctly. This was
tested by including a (nonexistent) makefile bar which is made as part of the
MAKEFILE_LIST target

The attached makefile uses the MAKEFILE_LIST variable to guarantee that the
target will be the name of the invoked makefile.  the targets foo and ./foo
can also be defined and the bug will still be apparent.

The MAKEFILE_LIST targets were specified as PHONY to guarantee that the
makefile gets updated.

Running on Kubuntu 6.10, GNU Make 3.81, built for x86_64-pc-linux-gnu




___

File Attachments:


---
Date: Tuesday 02/20/2007 at 20:39 UTC  Name: foo  Size: 0B   By: None



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #19113] cannot self-remake makefile starting with './'

[anonymous]

Additional Item Attachment, bug #19113 (project make):

File name: fooSize:0 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #19122] $* doesn't work as expected

[anonymous]

URL:
  

 Summary: $* doesn't work as expected
 Project: make
Submitted by: None
Submitted on: Thursday 02/22/2007 at 08:25 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: POSIX-Based
   Fixed Release: None

___

Details:

$* doesn't work for me - it returns empty string, while using in this way:
[code]
all: app.bin

app.bin:
touch $@
echo \$$* = $*
[/code]

When I run this Makefile, GNU Make 3.81 gives following output:
[output]
touch app.bin
echo \$* =
$* =
[output]

However, clearmake gives following (expected by me) result:
[output]
touch app.bin
echo \$* = app
$* = app
[/output]

$(*D) and $(*F) variables also return empty string in GNU Make.





___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #19122] $* doesn't work as expected

[anonymous]

Follow-up Comment #1, bug #19122 (project make):

It's behaving exactly as described in the GNU make info pages.  In
particular, as described in section 10.5.3 "Automatic Variables":

`$*'
 The stem with which an implicit rule matches (*note How
 Patterns Match: Pattern Match.).  If the target is
 dir/a.foo.b' and the target pattern is `a.%.b' then the
 stem is `dir/foo'.  The stem is useful for constructing
 names of related files.
<...>
 In an explicit rule, there is no stem; so `$*' cannot be
 determined in that way.  Instead, if the target name ends
 with a recognized suffix (*note Old-Fashioned Suffix
 Rules: Suffix Rules.), `$*' is set to the target name
 minus the suffix.  For example, if the target name is
 `foo.c', then `$*' is set to `foo', since `.c' is a
 suffix.  GNU `make' does this bizarre thing only for
 compatibility with other implementations of `make'.  You
 should generally avoid using `$*' except in implicit rules
 or static pattern rules.

 If the target name in an explicit rule does not end with
 a recognized suffix, `$*' is set to the empty string for
 that rule.

The rule in your example is an explicit rule and the target is not in the
default suffix list.  Therefore $* will be empty in that rule.  As mentioned
in the text above, use of $* in explicit rules is discouraged.  You should
either
a) hardcode the stem for the rule (there's only one target
   in your example, so there's only one stem),
b) extract the correct stem for the the target using $(patsubst)
   against $@, or whatever is appropriate, OR
c) add ".bin" to the suffix list by naming .bin as a dependency
   of the .SUFFIXES pseudo-target.


Philip Guenther


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #19226] False warning about a circular dependency

[anonymous]

URL:
  

 Summary: False warning about a circular dependency
 Project: make
Submitted by: None
Submitted on: Mittwoch 07.03.2007 um 09:28 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: Any
   Fixed Release: None

___

Details:

We are using make 3.81 under CygWin (Windows XP SP2).

I have the following makefile: "test.make":

--8<-
VPATH := ../dir/

all: a

.SECONDARY:

a: b b
   @echo "compile"

../dir/b:

--8<-

I am getting the following:

$ mkdir ../dir
$ touch ../dir/b
$ make -f test.make
make: Circular a <- b dependency dropped.
compile
$

Of course a depends on b, but why depends b on a?
When only one b is on the a line, the message isn't shown,
when the .SECONDARY: is missing it isn't shown and when
the b file is placed under ./dir the message is also not shown.

Paul Smith ([EMAIL PROTECTED]) confirmed this for Linux:
| I can confirm this on my Linux box.  It's even stranger
| if you look at the debug output, since make appears to
| try to build "b" right after it considers "all", without
| first considering "a" (according to the output).






___

File Attachments:


---
Date: Mittwoch 07.03.2007 um 09:28 UTC  Name: test.make  Size: 86B   By: None



___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #19298] simplify automatic generation of prerequisites example

[anonymous]

URL:
  

 Summary: simplify automatic generation of prerequisites
example
 Project: make
Submitted by: None
Submitted on: Sunday 03/11/2007 at 17:38 UTC
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: Any
   Fixed Release: None

___

Details:

in section 4.14 Generating Prerequisites Automatically

the example is quite complex using sed to add the *.d files as target. there
are easier ways to do that.

using an extra echo
%.d : %.c
  @echo -n $@" " > $@
  $(CC) $(CFLAGS) -MM $< >> $@

using gcc options -MT and -MF
%.d : %.c
  $(CC) $(CFLAGS) -MM -MT $@ -MT $(basename $@).o -MF $@ $<






___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #19309] parallel make issue with archive members

[anonymous]

URL:
  

 Summary: parallel make issue with archive members
 Project: make
Submitted by: None
Submitted on: Monday 03/12/2007 at 02:08 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: POSIX-Based
   Fixed Release: None

___

Details:

Hello,

I am having issues with parallel make and archive members.  I have a rule
which puts all the changed objects in the same archive.  However, it doesn't
work with the parallel "make -j2" option.

1. Copy this Makefile into a directory and create some files.
mkdir makeprob
cd makeprob
touch foo1.cc
touch foo2.cc
touch foo3.cc
touch foo4.cc

2. Create destination directory:
mkdir /tmp/dest

3. Do a make -j2 and it works fine:
> make -j2
g++   -c -o /tmp/dest/foo1.o foo1.cc
g++   -c -o /tmp/dest/foo2.o foo2.cc
g++   -c -o /tmp/dest/foo3.o foo3.cc
g++   -c -o /tmp/dest/foo4.o foo4.cc
cd /tmp/dest; \
ar rv libfoo.a foo1.o foo2.o foo3.o foo4.o;
ar: creating libfoo.a
a - foo1.o
a - foo2.o
a - foo3.o
a - foo4.o

4. touch all the .cc files and do another make -j2 and it does not load the
archive work without doing a second make:
> touch *cc
> make -j2
g++   -c -o /tmp/dest/foo1.o foo1.cc
g++   -c -o /tmp/dest/foo2.o foo2.cc
g++   -c -o /tmp/dest/foo3.o foo3.cc
g++   -c -o /tmp/dest/foo4.o foo4.cc
cd /tmp/dest; \
ar rv libfoo.a ;
> make -j2
cd /tmp/dest; \
ar rv libfoo.a /tmp/dest/foo1.o /tmp/dest/foo2.o /tmp/dest/foo3.o
/tmp/dest/foo4.o;
r - /tmp/dest/foo1.o
r - /tmp/dest/foo2.o
r - /tmp/dest/foo3.o
r - /tmp/dest/foo4.o 

5. Do the same procedure with single threaded make and it works fine:
> touch *.cc
> make
g++   -c -o /tmp/dest/foo1.o foo1.cc
g++   -c -o /tmp/dest/foo2.o foo2.cc
g++   -c -o /tmp/dest/foo3.o foo3.cc
g++   -c -o /tmp/dest/foo4.o foo4.cc
cd /tmp/dest; \
ar rv libfoo.a foo1.o foo2.o foo3.o foo4.o;
r - foo1.o
r - foo2.o
r - foo3.o
r - foo4.o

It is my suspicion this has something to do with vpath and parallel make. 
Please let me know if you are able to reproduce this.  This was not an issue
before I started using VPATH and a destination directory outside of the
source area.  My temporary fix is to change the $? in the archive rule to
$(CXX_OBJS).  This is make 3.81 and I am able to reproduce it on both a 32
bit and a 64 bit gentoo system.

I tried the same tests at work and it seems that many of the most recent
versions of Make exhibit this issue.

Thanks,
Juan




___

File Attachments:


---
Date: Monday 03/12/2007 at 02:08 UTC  Name: Makefile  Size: 302B   By: None
Makefile exhibiting issue.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #19626] Unexpected environment variable modification in command

[anonymous]

URL:
  

 Summary: Unexpected environment variable modification in
command
 Project: make
Submitted by: None
Submitted on: mercredi 18.04.2007 à 11:44 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.80
Operating System: Any
   Fixed Release: None

___

Details:

When running following Makefile with GNU make 3.80 on Cygwin/Solaris/Linux it
outputs value of the Make variable instead of environment variable in case an
environment variable of the same name than Make variable exists.
[~]$ cat Makefile
IN_ENV = from_make
NOT_IN_ENV = from_make

all:
echo $${IN_ENV}
echo $${NOT_IN_ENV}

[~]$ make
echo ${IN_ENV}

echo ${NOT_IN_ENV}

=> that's OK
[~]$ export IN_ENV=from_env
[~]$ make
echo ${IN_ENV}
from_make
echo ${NOT_IN_ENV}

=> As variables are not exported I expect getting:
echo ${IN_ENV}
from_env
echo ${NOT_IN_ENV}






___

Reply to this item at:

  

___
  Message posté via/par Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #19448] Re-exec after "include file rebuild" is more dependent on filesystem timestamps than strictly necessary.

[anonymous]

Follow-up Comment #1, bug #19448 (project make):

I'm going to disagree with the original submitter.  Make should be
conservative: if it's not certain that a file is up to date, it should be
rebuilt.

In particular, in the absence of other information, equal timestamps should
be considered NOT up to date.  It is better to waste a bit of CPU time than
to risk having an out-of-date file.
I'm pretty sure that was the behavior of the original Unix make, and for good
reason.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #19448] Re-exec after "include file rebuild" is more dependent on filesystem timestamps than strictly necessary.

[anonymous]

Follow-up Comment #2, bug #19448 (project make):

I will disagree with the original poster.  Make's job is to be conservative:
after typing "make", you should be able to count on it that everything is up
to date.  If that invokes a bit of extra work, the lost CPU time is far
better than risking something not being updated.

For that reason, the original Unix make considered equal timestamps to be
"out of date" unless it had other information to the contrary.  So if foo
depends on bar and I type "make foo; touch bar; make foo", foo should be made
the second time REGARDLESS of issues of timestamp resolution and clock races.

The current behavior (which seems to be the result of a recent change) is
incorrect.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #19108] Pattern rules with multiple target patterns do not honor the dependencies of all targets correctly

[anonymous]

Follow-up Comment #1, bug #19108 (project make):

Hello Christoph,

I believe that the problem lies in your Makefile rule:

%.tgt1 %.tgt2: %.src
cp $< $(patsubst %.src,%.tgt1,$<)
cp $< $(patsubst %.src,%.tgt2,$<) 

This rule states that %.tgt1 depends on %.src and %.tgt2 depends on %.src.
However this single rule should NOT generate both files at once. I believe
that if you rewrite your rule as follows:

%.tgt1 %.tgt2: %.src
cp $< $@

then it would work as desired.

The issue is that if multiple targets pattern rule is defined, make runs
commands for one fitting target at the time. Now, when you build "final",
make sees that it depends on "x". "x" depends on x.tgt1, which can be built
due to no further dependencies, so it calls your rules to build x.tgt1 ONLY.
But your rule builds also x.tgt2, so when make comes back to check other
dependencies of x, x.tgt2 is already up-to-date and does not need to be
followed.

My belief is that no rule should make more targets then make wants. Every
rule should only generate [EMAIL PROTECTED] Otherwise one is asking for trouble.

Best regards,
Krzysztof Malinowski

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #19975] Add function: $(mtime foo.c) -> 1180203683

[anonymous]

Follow-up Comment #1, bug #19975 (project make):

Now that the AT&T nmake tool is opensource, you might be better off seeing if
that will serve your needs rather than writing something on top of GNU make.

http://www.research.att.com/sw/download/

nmake already remembers the mtime for files and considers the file is out of
date if the prerequsites mtime has changed.

It also remembers the values of flags, so if you change say "CFLAGS" (it
calls it CCFLAGS for consistency with other languages) then it knows it
should recompile everything.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #20033] parallel (-j2) make with $(eval) construct segfaults

[anonymous]

URL:
  

 Summary: parallel (-j2) make with $(eval) construct
segfaults
 Project: make
Submitted by: None
Submitted on: Friday 06/01/2007 at 10:48 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: POSIX-Based
   Fixed Release: None

___

Details:

Hello,

At work I have a (proprietary, sorry) makefile where I use an $(eval)
construct. It goes like

foo: bar
$(eval CHECKSUM := $(word 1,$(shell cat $^ | sha1sum))) $(if
$(wildcard $(CACHEDIR)/$(CHECKSUM)), $(call do-copy,$(CHECKSUM)), $(call
do-dct4-selection,$(CHECKSUM)))

This runs nicely with a plain make but if I try make -j2 I get a segfault. I
have captured this in gdb, output below


(gdb) bt
#0  eval_buffer (
buffer=0x819abb8 "CHECKSUM := ac2773ef9cb98feab91b3ddfeedc20019d1516c3")
at read.c:430
#1  0x08050012 in func_eval (o=0x819aae9 "[\230[", argv=0x0,
funcname=0x8062e38 "eval") at function.c:1369
#2  0x080506a8 in expand_builtin_function (o=0x819aae9 "[\230[",
argc=135900088, argv=0xfeffa8b0, entry_p=0xffca) at function.c:2115
#3  0x08050819 in handle_function (op=0xfeffa944, stringp=0x818ea38)
at function.c:2213
#4  0x0804c630 in variable_expand_string (line=0x0,
string=0x818ea00 "\t$(eval CHECKSUM := $(word 1,$(shell cat $^ |
sha1sum))) $(if $(wildcard $(CACHEDIR)/$(CHECKSUM)), $(call
do-copy,$(CHECKSUM)), $(call do-dct4-selection,$(CHECKSUM)))", length=-1) at
expand.c:253
#5  0x0804c9a6 in variable_expand (
line=0x818ea00 "\t$(eval CHECKSUM := $(word 1,$(shell cat $^ | sha1sum)))
$(if $(wildcard $(CACHEDIR)/$(CHECKSUM)), $(call do-copy,$(CHECKSUM)), $(call
do-dct4-selection,$(CHECKSUM)))") at expand.c:418
#6  0x0804ca40 in variable_expand_for_file (
line=0xffca , file=0x819abb8)
at expand.c:463
#7  0x0804cc15 in allocated_variable_expand_for_file (
line=0x818ea00 "\t$(eval CHECKSUM := $(word 1,$(shell cat $^ | sha1sum)))
$(if $(wildcard $(CACHEDIR)/$(CHECKSUM)), $(call do-copy,$(CHECKSUM)), $(call
do-dct4-selection,$(CHECKSUM)))", file=0x80725b8) at expand.c:548
#8  0x08053319 in new_job (file=0x80725b8) at job.c:1600
#9  0x0805c28a in update_file_1 (file=0x80725b8, depth=0) at remake.c:761
#10 0x0805b984 in update_file (file=0x80725b8, depth=0) at remake.c:307
#11 0x0805b63f in update_goal_chain (goals=0x80ba8d8) at remake.c:154
#12 0x080551a2 in main (argc=7, argv=0xfeffc454, envp=0xfeffc474)
at main.c:2198
(gdb) print reading_file
$1 = (const struct floc *) 0x0

line 430 at read.c:

  ebuf.floc = *reading_file;

So we try to dereference a NULL pointer here. As stated this is make 3.81. 

I hope this is of help, otherwise I'll try to provide more information.

Cheers,
  Rasmus




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #20033] parallel (-j2) make with $(eval) construct segfaults

[anonymous]

Follow-up Comment #1, bug #20033 (project make):

Hi, its me again. Find below a trivial makefile to recreate this. run 'make
setup && make -j2' to get a segfault.

Cheers,
  Rasmus

A := $(wildcard *.a)

.PHONY: all
all: $(A:.a=.b)

.PHONY: clean
clean:
rm -f $(A)

.PHONY: setup
setup:
@touch 1.a 2.a 3.a 4.a 5.a 6.a

define d1
@echo lala $(1)
@sleep 1
endef

define d2
@echo tyty $(1)
@sleep 1
endef

%.b : %.a
$(eval CHECKSUM := $(word 1,$(shell cat $^ | sha1sum))) $(if
$(wildcard $(CACHEDIR)/$(CHECKSUM)),\
$(call d1,$(CHECKSUM)),\
$(call d2,$(CHECKSUM)))


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #19108] Pattern rules with multiple target patterns do not honor the dependencies of all targets correctly

[anonymous]

Follow-up Comment #3, bug #19108 (project make):

I think I'm seeing some symptoms that are essentially the same bug. I'm using
make 3.80.

I have a rule that generates N targets from some dependencies using a set of
commands, setup just like the original poster.

If I run "make", everything is fine; the commands are run once, and make
knows that all the N targets have been updated just fine.

However, if I run "make -j 2", make spawns off two copies of the commands,
presumably because when it's attempting to build each of the N targets, it
doesn't check the "make_also" to see if some other target of this rule is
already being built. Once a target has finished building, it marks all the
"make_also" as being built, and so doesn't spawn the commands again for the
other N-2 targets.

Probably, the original reporter's problem is also a lack of checking
make_also, but in this case, a lack of checking the dependencies rather than
the build-in-progress value of the make_also targets.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #712] GNU make can't handle spaces in pathnames

[anonymous]

Follow-up Comment #7, bug #712 (project make):

How about simply: 

$(notdir "C:\Program Files\Company Name\Binary1.dll" "C:\Program
Files\Company Name\Binary2.dll")  

I think it's pretty clear what should happen here.  How hard is it to support
quoting properly?  After all most shells know how to quote intrinsically, and
GNU make is creating shell scripts for most things.

Heck, even *DOS* can accept quoted arguments.  Same argument for targets.  If
I expect spaces, I (should be able to):

"%.util" : "$(TEMP_PATH)/%.exe"
  cp "$*" "$(OUT_PATH)/$(notdir $*)"

Seems natural enough, is this type of thing I need to do in most
batch/shell/scripts anyway.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

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

[anonymous]

Follow-up Comment #14, bug #15919 (project make):

(comment by J. David Bryan, original submitter)

The patch from Icarus Sperry does fix the original problem.  However, it
appears to introduce a new one.

I have taken the original make-3.81 sources and added the patch to produce
"make-381p".  Then, with this makefile:

%.c : %.b
cp $< $@

%.b : %.a
cp $< $@

all : 1.c 2.c

...executing this command in an otherwise empty directory:

$ touch 1.a 2.a && make-381p -j 2

...produces this output:

cp 1.a 1.b
cp 2.a 2.b
cp 1.b 1.c
cp 2.a 2.b  [ <-- NOTE ]
cp 2.b 2.c
rm 1.b 2.b

...whereas the stock make-3.81 with the same command produces:

cp 1.a 1.b
cp 2.a 2.b
cp 1.b 1.c
cp 2.b 2.c
rm 1.b 2.b

Note that the patched version copies 2.a to 2.b twice.  Running the patched
version with "-j 1" produces the correct behavior.

I've confirmed this on sparc-sun-solaris2.9 as well as the x86 Win32
version.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

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

[anonymous]

Additional Item Attachment, bug #15919 (project make):



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

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

[anonymous]

Follow-up Comment #17, bug #15919 (project make):

(comment by J. David Bryan, original submitter) 

> ...they can not even spell my name correctly!

My apologies.  Of course, I noted the misspelling as soon as I had posted
comment 14, but there seemed to be no way to edit a bug post after
submission.  I thank you for the original patch and the followup, and I'm
sorry that the typo caused you such distress.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #20394] vpath directive drops entries

[anonymous]

URL:
  

 Summary: vpath directive drops entries
 Project: make
Submitted by: None
Submitted on: Samstag 07.07.2007 um 08:09 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: POSIX-Based
   Fixed Release: None

___

Details:

With GNU make v3.81 (as well as earlier versions, eg. 3.81beta4 and v3.80),
the vpath directive for libraries seems to "forget" entries under certain
circumstances.

Example:

A project with the following directory layout:

Makefile
foo1/
 foo1/Makefile
foo2/
 foo2/Makefile
foo3/
 foo3/Makefile
foo4/
 foo4/Makefile
foo5/
 foo5/Makefile
foo6/
 foo6/Makefile
foo7/
 foo7/Makefile
foo8/
 foo8/Makefile
include/
lib/

and this top-level Makefile:


#
SUBDIRS  := foo1 foo2 foo3 foo4 foo5 foo6 foo7 foo8
TARGET   := app
LIBDIRS  := $(patsubst %,-L%,$(SUBDIRS))
LIBS := $(patsubst %,-l%,$(SUBDIRS))


vpath %.h include
vpath %.a lib $(SUBDIRS)


all: subdirs $(TARGET)

subdirs:
@(for module in $(SUBDIRS); \
do \
$(MAKE) -w -C $$module -f Makefile $(MAKECMDGOALS); \
done)

$(TARGET): $(LIBS)
$(CC) -o $@ $(LIBDIRS) $(LIBS)
#


and this as each of the subdir-Makefiles:


LIBNAME := $(shell basename `pwd`)
LIBFILENAME := lib$(LIBNAME).a
LIBTARGET := $(LIBFILENAME)

all: $(LIBTARGET)

$(LIBTARGET):
touch $@




Output:


$ make
make[1]: Entering directory `/home/luna/tmp/testmake3/foo1'
touch libfoo1.a
make[1]: Leaving directory `/home/luna/tmp/testmake3/foo1'
make[1]: Entering directory `/home/luna/tmp/testmake3/foo2'
touch libfoo2.a
make[1]: Leaving directory `/home/luna/tmp/testmake3/foo2'
make[1]: Entering directory `/home/luna/tmp/testmake3/foo3'
touch libfoo3.a
make[1]: Leaving directory `/home/luna/tmp/testmake3/foo3'
make[1]: Entering directory `/home/luna/tmp/testmake3/foo4'
touch libfoo4.a
make[1]: Leaving directory `/home/luna/tmp/testmake3/foo4'
make[1]: Entering directory `/home/luna/tmp/testmake3/foo5'
touch libfoo5.a
make[1]: Leaving directory `/home/luna/tmp/testmake3/foo5'
make[1]: Entering directory `/home/luna/tmp/testmake3/foo6'
touch libfoo6.a
make[1]: Leaving directory `/home/luna/tmp/testmake3/foo6'
make[1]: Entering directory `/home/luna/tmp/testmake3/foo7'
touch libfoo7.a
make[1]: Leaving directory `/home/luna/tmp/testmake3/foo7'
make[1]: Entering directory `/home/luna/tmp/testmake3/foo8'
touch libfoo8.a
make[1]: Leaving directory `/home/luna/tmp/testmake3/foo8'
make: *** No rule to make target `-lfoo8', needed by `app'.  Stop.



Interestingly, it works again if any one of these actions is taken:
* the lib/ directory is removed
* the include/ directory is removed
* one of the entries of SUBDIRS is removed
* the line with *vpath %.h include* is removed
* the line with *vpath %.h include* is put _after_ the *vpath %.a ...*
* in the line with *vpath %.a ...*, the entry *lib* is moved to the end of
the list




___

File Attachments:


---
Date: Samstag 07.07.2007 um 08:09 UTC  Name: make_vpath_error.tar.gz  Size:
845B   By: None
Example directory structure, as described above


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #20394] vpath directive drops entries

[anonymous]

Follow-up Comment #1, bug #20394 (project make):

gmake caches directories from the 10th on. So it will not see a file in those
directories if it didn't exist initially (except under windows NT, where it
checks the directory timestamps). 

Just looks like foo1..8 plus lib, include and . were one more than 10.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #20394] vpath directive drops entries

[anonymous]

Follow-up Comment #3, bug #20394 (project make):

It would maybe make sense to rely on the directory cache only for
intermediate search and match-anything rules. Because these two alone
increase the number of file-queries by a factor of about 10. That is just
from the 5 built-in rules (which moreover likely nobody ever uses).

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #20394] vpath directive drops entries

[anonymous]

Follow-up Comment #5, bug #20394 (project make):

Timestamps are a different matter, gmake doesn't use the cache to check
timestamps of files. Also, what I meant was *chained* rules with intermediate
files, not first-level implicit rules. Basically it is so that gmakes spends
all win from the cache on it's own built-in chained and match-anything rules.
For the user the cache brings no benefit, only the known inconsistencies.

However it is maybe right that two different behaviours is too confusing.
Probably it would be better to use no cache at all and get rid of some exotic
built-in rules instead.

As to empty the cache after each subprocess, well it could work too. I don't
quite see the deal with the counter though, shouldn't a boolean 'is_stale'
suffice?


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #20394] vpath directive drops entries

[anonymous]

Follow-up Comment #7, bug #20394 (project make):

As to when to use the cache vs. avoid it, I actually meant the opposite from
what you wrote. Maybe it's more clear with a practical example:

$ time make -C fltk-1.1.7, up-to-date, on a (slow) Ubuntu box:
make (3.81b4, as is): 
- 3.8 sec
make (cvs, no default_terminal_rules, no cache): 
- 2.0 sec


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #20542] Regression: windows gnumake + MKS shell + Special Shell Chars

[anonymous]

URL:
  

 Summary: Regression: windows gnumake + MKS shell + Special
Shell Chars
 Project: make
Submitted by: None
Submitted on: Friday 07/20/2007 at 12:48 UTC
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: MS Windows
   Fixed Release: None

___

Details:

Hi, 

I think that literalizing special characters does not work anymore as it used
to in 3.80. I'm using gnumake on windows together with a shell from MKS.

Given the following makefile:

--
CPP_FLAGS += /D "MYPROG=\"HALLO(TM)\""

%.exe : %.c
 cl.exe $(CPP_FLAGS)  $<
--
 and this little C-File:
--
#include 

int main(int argc, char** argv) {
printf("%s", MYPROG);
return 0;
}
--


v 3.80 called the compiler just fine, it compiles and links.
v 3.81 causes the shell to complain and exit:

syntax error: got (, expecting Newline
gnumake: *** [a.exe] Error 1

Same shell, same environment, only difference the gnumake version used.

The command echoe'd by gnumake looks the same in both cases:

cl.exe /D "MYPROG=\"HALLO(TM)\""  a.c

---

The error does not happen if I use cmd.exe as shell, but that is not an
option, unfortunately..

Kind Regards,

Thomas Stüfe







___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #20542] Regression: windows gnumake + MKS shell + Special Shell Chars

[anonymous]

Follow-up Comment #2, bug #20542 (project make):

The echo from gmake is not relevant. Try "gmake --debug=jobs ..." to see the
real command-line. 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #20549] make -n doesn't work recursively

[anonymous]

URL:
  

 Summary: make -n doesn't work recursively
 Project: make
Submitted by: None
Submitted on: Saturday 07/21/2007 at 11:01 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: MS Windows
   Fixed Release: None

___

Details:

all clean:
$(MAKE) subdirs "TARGET=$@"

$ make -n
make subdirs "TARGET=all"
process_begin: CreateProcess(NULL, "", ...) failed.
make (e=161): Die Pfadangabe ist ungültig.
make381: *** [all] Error 161





___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #20550] Crash with setting SHELL from the commandline

[anonymous]

URL:
  

 Summary: Crash with setting SHELL from the commandline
 Project: make
Submitted by: None
Submitted on: Saturday 07/21/2007 at 11:02 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: MS Windows
   Fixed Release: None

___

Details:

$ make SHELL=$(COMSPEC)
make: Interrupt/Exception caught (code = 0xc005, addr = 0x41ddf2)





___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #20550] Crash with setting SHELL from the commandline

[anonymous]

Follow-up Comment #2, bug #20550 (project make):

The patch applies, but it doesn't compile. See attached
"build_w32_errors.txt".

(file #13415)
___

Additional Item Attachment:



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #20549] make -n doesn't work recursively

[anonymous]

Follow-up Comment #2, bug #20549 (project make):

Hm, the patch doesn't apply against current CVS ...


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

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

[anonymous]

Follow-up Comment #21, bug #15919 (project make):

(comment by J. David Bryan, original submitter)

I have built separate versions of make with Paul's patch from Comment #20 and
Icarus' patch from Comment #18.  Both fix the problem in the original bug
submission.  However, Paul's patch appears to fail with this sequence of
commands (using the original makefile):

$ touch test.0 && make-p
touch test.1
touch test.2
touch test.3
touch test.int
touch test.4
rm test.int

[the above is correct]

$ touch test.0 && make-p
touch test.1
touch test.2
touch test.int
touch test.4
rm test.int

[the above is correct -- test.3 is not remade]

$ touch test.0 test.3 && make-p
touch test.int
touch test.4
rm test.int

[the above is incorrect -- test.1 and test.2 are not remade]

If I repeat the last command using Icarus' patched version, it works as
expected:

$ touch test.0 test.3 && make-i
touch test.1
touch test.2
touch test.int
touch test.4
rm test.int

[the above is correct]

If I run the last command with Paul's patched version, I note the following
lines in the debug output log produced with the "-d" option:

Considering target file `test.2'.
File `test.2' was considered already.

...except that test.2 wasn't previously considered, according to the log.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #20995] \ along multiple lines lines for '...' doesn't work

[anonymous]

Follow-up Comment #2, bug #20995 (project make):

you can forget about it - it's a feature
(http://www.gnu.org/software/make/manual/make.html#Splitting-Lines)

RTFM :-)

rgds!

Frank

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #20995] \ along multiple lines lines for '...' doesn't work

[anonymous]

URL:
  

 Summary: \ along multiple lines lines for '...' doesn't work

 Project: make
Submitted by: None
Submitted on: Friday 09/07/2007 at 12:53 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: None
   Fixed Release: None

___

Details:

> cat Makefile 
test::
echo "test1"
echo "test2"
echo "hallo \
this is a broken line"
echo 'hello \
this is another broke line' 

3.80 (old behavior):
> make test
echo "test1"
test1
echo "test2"
test2
echo "hallo \
this is a broken line"
hallo  this is a broken line
echo 'hello \
this is another broke line' 
hello this is another broke line### !!!

3.81 (new behavior):
> make test
echo "test1"
test1
echo "test2"
test2
echo "hallo \
this is a broken line"
hallo this is a broken line
echo 'hello \
this is another broke line' 
hello \ ### !!!
this is another broke line  ### !!!


This break execution of s.th. else than 'echo' (e.g. 'perl').

I guess it's a bug?

rgds!

Frank




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #21198] Wrong order of prerequisites with 3.81/CVS

[anonymous]

URL:
  

 Summary: Wrong order of prerequisites with 3.81/CVS
 Project: make
Submitted by: None
Submitted on: Sunday 09/30/2007 at 18:29 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: CVS
Operating System: Any
   Fixed Release: None

___

Details:

Wrong order of prerequisites with 3.81/CVS

all : A B C
all : ; @echo $@ -- $^
all : D E F
A B C D E F : ; @echo $@

$ gmake381
D
E
F
A
B
C
all -- D E F A B C





___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #21231] $(wildcard ) function sometimes fails very strangely

[anonymous]

Follow-up Comment #1, bug #21231 (project make):

this appears to be normal behavior. wildcard reads from its own cache and the
current dir is cached upon startup. -- put out.txt in a subdir and you will
see the difference. The subdir is not cached until the wildcard is performed.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #21670] implicit rule ignored for prerequisite that is produced by .DEFAULT

[anonymous]

Follow-up Comment #1, bug #21670 (project make):

Looks like a regression in 3.81, as the makefile works as desired with 3.80. 
It seems the interpretation of step 5.c of the algorithm in section 10.8,
"Implicit Rule Search Algorithm" of the info pages changed:

   c. Test whether all the prerequisites exist or ought
  to exist. (If a file name is mentioned in the
  makefile as a target or as an explicit
  prerequisite, then we say it ought to exist.)

  If all prerequisites exist or ought to exist, or
  there are no prerequisites, then this rule applies.

make.c is mentioned in the makefile as an explicit prerequisite (for prog),
so make should conclude that "it ought to exist" and therefore the suffix rule
for .c.o should apply and block consideration of .DEFAULT for hello.o.

Note that 3.81 behaves as desired if this is added to the makefile:
 make.o: make.c

It's like 3.81 interprets the phrase "explicit prerequisite" to mean
"explicit prerequisite of the current target" in step 5.c.


That said, the .DEFAULT rule in the example seems like the wrong tool for the
job here.  The right way to tell GNU make that the backup/ directory may
contain a copy of a missing prerequisite would be this:

%:: backup/%
ln -s $< $@

Note that with that instead of the .DEFAULT rule, GNU make operates
correctly, even after removing the 'make.c' dependency for the 'prog' target. 
(The rule for 'prog' doesn't use 'make.c', only 'make.o', so it has no real
reason to depend on 'make.c'.)


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #21716] The following works in 3.80 but not in 3.81

[anonymous]

URL:
  

 Summary: The following works in 3.80 but not in 3.81
 Project: make
Submitted by: None
Submitted on: Tuesday 12/04/2007 at 09:01 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: POSIX-Based
   Fixed Release: None

___

Details:

$(EXECDIR)/ipadb $(EXECDIR)/mnconv $(EXECDIR)/mksubnet \ 
  $(EXECDIR)/netnamconv $(EXECDIR)/tspnamconv : $$(@F) 

on 3.81
make[2]: *** No rule to make target `$(@F)', needed by `../../bin/mnconv'. 
Stop   




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #21823] Potential NULL pointer dereference on hash.c, hash_insert

[anonymous]

Follow-up Comment #1, bug #21823 (project make):

Just because there is a check for NULL does not necessarily mean that a NULL
value can ever happen, "potentially". Unless you assume that all statements in
a program serve a particular purpose. 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #21716] The following works in 3.80 but not in 3.81

[anonymous]

Follow-up Comment #2, bug #21716 (project make):

The change in behavior is listed in the 3.81 NEWS file.  To quote:

* WARNING: Backward-incompatibility!
  GNU make now implements a generic "second expansion"
  feature on the prerequisites of both explicit and implicit
  (pattern) rules.  In order to enable this feature, the
  special target '.SECONDEXPANSION' must be defined before
  the first target which takes advantage of it.  If this
  feature is enabled then after all rules have been parsed
  the prerequisites are expanded again, this time with all
  the automatic variables in scope.  This means that in
  addition to using standard SysV $$@ in prerequisites
  lists, you can also use complex functions such as
  $$(notdir $$@) etc.  This behavior applies to implicit
  rules, as well, where the second expansion occurs when
  the rule is matched.  However, this means that when
  .SECONDEXPANSION' is enabled you must double-quote any
  "$" in your filenames; instead of "foo: boo$$bar" you
  now must write "foo: foobar".  Note that the SysV
  $$@ etc. feature, which used to be available by default,
  is now ONLY available when the .SECONDEXPANSION target
  is defined.  If your makefiles take advantage of this
  SysV feature you will need to update them.


So, add the line
   .SECONDEXPANSION:
to the makefile somewhere before any uses of $$(@F), etc.  With that, the
makefile will work with both 3.80 and 3.81.

Philip Guenther


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #21984] make detects circular dependency when there is none

[anonymous]

URL:
  

 Summary: make detects circular dependency when there is none
 Project: make
Submitted by: None
Submitted on: Tuesday 01/08/2008 at 21:08 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: CVS
Operating System: POSIX-Based
   Fixed Release: None

___

Details:

When running make with the makefile

VPATH := /etc
default: alpha beta
/etc/gamma:
.SECONDARY:
alpha: gamma
beta: gamma

it detects a circular dependency that does not exist:

make: Circular beta <- gamma dependency dropped.
make: Nothing to be done for `/etc/default'.

Obviously dropping this dependency is a problem for the correctness of the
build.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #22010] The increased stack rlimit is inherited by the subprocesses to make.

[anonymous]

URL:
  

 Summary: The increased stack rlimit is inherited by the
subprocesses to make.
 Project: make
Submitted by: None
Submitted on: Saturday 01/12/2008 at 22:23 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: POSIX-Based
   Fixed Release: None

___

Details:

As has been noted in bug #18396, the excessive use of stack in make is not a
good thing. But worse is that the increased rlimit is inherited by the
subprocesses started by the make.

Eg:
$ make --version
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for ia64-unknown-linux-gnu
$ cat foo.mk
foo:
: && ulimit -a
$ make -f foo.mk
core file size  (blocks, -c) 0
data seg size   (kbytes, -d) unlimited
scheduling priority (-e) 0
file size   (blocks, -f) unlimited
pending signals (-i) 4056
max locked memory   (kbytes, -l) 128
max memory size (kbytes, -m) unlimited
open files  (-n) 1024
pipe size(512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority  (-r) 0
stack size  (kbytes, -s) 2097152
cpu time   (seconds, -t) unlimited
max user processes  (-u) 4056
virtual memory  (kbytes, -v) unlimited
file locks  (-x) unlimited

Ok, that you want to use stack, but wouldn't you say that ~2GB is a bit
excessive?

Unfortunately, some parts of glibc aren't prepared for those kinds of stack
sizes (eg pthreads, which causes some applications to fail intermittently with
SIGSEGV).

Please at least restore the ulimits for the subprocesses.





___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #22198] wrong target name - possibly buffer overflow with long shell-result

[anonymous]

URL:
  

 Summary: wrong target name - possibly buffer overflow with
long shell-result
 Project: make
Submitted by: None
Submitted on: Freitag 01.02.2008 um 09:36 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: POSIX-Based
   Fixed Release: None

___

Details:

With the attached makefile, when I do

make |& cat -v

I get the output

make: *** No rule to make target `^[]2', needed by `file'.  Stop.

which names a target containing an escape character; that is wrong, since
such a target is not mentioned in the makefile.
Perhaps the long $(shell ...) result string is causing a buffer overflow.



___

File Attachments:


---
Date: Freitag 01.02.2008 um 09:36 UTC  Name: GNUmakefile  Size: 788B   By:
None



___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #22198] wrong target name - possibly buffer overflow with long shell-result

[anonymous]

Follow-up Comment #1, bug #22198 (project make):

I'm sorry, this bug report is erroneous.
The csh startup script did indeed output an escape sequence, so make was
absolutely correct.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #22379] Segmentation fault with wildcard archive rule

[anonymous]

URL:
  

 Summary: Segmentation fault with wildcard archive rule
 Project: make
Submitted by: None
Submitted on: jeudi 21.02.2008 à 18:42 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: POSIX-Based
   Fixed Release: None

___

Details:

Here is a small make file that exhibit some sort of a memory corruption
leading to the crash

I use plain vanilla debian etch with libc6 2.3.6.

Just run the attached make file twice to trigger the bug

.PHONY: all

all: bug.crash

%.bug(*.txt) :
   @echo whatever > x1.txt
   @echo whatever > x2.txt
   ar Srv bug.bug x1.txt x2.txt
   rm -rf x1.txt x2.txt

%.crash : %.bug(*.txt)
   @echo CRASH condition ready, just re-run
--- 




___

Reply to this item at:

  

___
  Message posté via/par Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #22434] Consider a dependancy as target file and try to make the file

[anonymous]

Additional Item Attachment, bug #22434 (project make):

File name: GnuMakeBug.tar.gz  Size:7 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #22442] Old-style cancelation of implicit rules

[anonymous]

URL:
  

 Summary: Old-style cancelation of implicit rules
 Project: make
Submitted by: None
Submitted on: Friday 02/29/2008 at 01:09 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: POSIX-Based
   Fixed Release: None

___

Details:

I'd like to write portable makefiles that avoid the "%"
mechanism, but this leaves me no way of cancelling implicit
rules.  According to POSIX, it should be possible to cancel
a rule be writing something like

rule:  ;

But in gnu make version 3.81, this only results in changing
rule so that it does nothing.  For example if I want to 
control how C++ gets compiled and linked I define

.cc.o:
   My compile command

.o :
   My link command

But in the special case where there is only one .cc file
needed to make an executable the default ".cc" rule kicks
in and bypasses my commands.





___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #22531] Make 3.81 May Incorrectly Regard Object Dependencies as Complete

[anonymous]

URL:
  

 Summary: Make 3.81 May Incorrectly Regard Object
Dependencies as Complete
 Project: make
Submitted by: None
Submitted on: Monday 03/10/2008 at 15:17 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: POSIX-Based
   Fixed Release: None

___

Details:

I have been establishing a build environment and infrastructure for a project
I am working on.

In the course of doing so, I have found some inexplicable behavior in make
3.81 when compiling and generating archive libraries in a pristine build tree.
The issue manifests itself on both Mac OS X / Darwin on i686 and Ubuntu
Desktop 7.10 on i686.

The behavior is that make creates the necessary object, depend and results
directories based on order-only prerequisites in my implicit rules, correctly
compiles the first source file into an object for the archive library, but
then regards all other objects as complete and then tries to archive the
library with non-existent and un-built objects:

% make
mkdir -p .depends
mkdir -p .objects
gcc -g -O1 -MD -MP -MF .depends/a.d -c -o .objects/a.o a.c
mkdir -p .results
ar -cr .results/libalphabet.a .objects/a.o .objects/b.o .objects/c.o
.objects/d.o .objects/e.o .objects/f.o .objects/g.o .objects/h.o
ar: .objects/b.o: No such file or directory
ar: .objects/c.o: No such file or directory
ar: .objects/d.o: No such file or directory
ar: .objects/e.o: No such file or directory
ar: .objects/f.o: No such file or directory
ar: .objects/g.o: No such file or directory
ar: .objects/h.o: No such file or directory
make: *** [.results/libalphabet.a] Error 1

If I then run make again, the order-only prerequisites having been already
satisfied this time around, things work as expected:

% make
gcc -g -O1 -MD -MP -MF .depends/b.d -c -o .objects/b.o b.c
gcc -g -O1 -MD -MP -MF .depends/c.d -c -o .objects/c.o c.c
gcc -g -O1 -MD -MP -MF .depends/d.d -c -o .objects/d.o d.c
gcc -g -O1 -MD -MP -MF .depends/e.d -c -o .objects/e.o e.c
gcc -g -O1 -MD -MP -MF .depends/f.d -c -o .objects/f.o f.c
gcc -g -O1 -MD -MP -MF .depends/g.d -c -o .objects/g.o g.c
gcc -g -O1 -MD -MP -MF .depends/h.d -c -o .objects/h.o h.c
ar -cr .results/libalphabet.a .objects/b.o .objects/c.o .objects/d.o
.objects/e.o .objects/f.o .objects/g.o .objects/h.o
ranlib .results/libalphabet.a

It works successfully under 3.80 but fails under 3.81:

3.81


% /usr/gnu/bin/make --version
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for i386-apple-darwin8.11.1

% /usr/gnu/bin/make -r -R clobber
rm -f .depends/a.d .depends/b.d .depends/c.d .depends/d.d .depends/e.d
.depends/f.d .depends/g.d .depends/h.d
rm -f .objects/a.o .objects/b.o .objects/c.o .objects/d.o .objects/e.o
.objects/f.o .objects/g.o .objects/h.o
rm -f .results/libalphabet.a
rm -rf .objects/
rm -rf .depends/
rm -rf .results/

% /usr/gnu/bin/make -r -R 
mkdir -p .depends
mkdir -p .objects
gcc -g -O1 -MD -MP -MF .depends/a.d -c -o .objects/a.o a.c
mkdir -p .results
ar -cr .results/libalphabet.a .objects/a.o .objects/b.o .objects/c.o
.objects/d.o .objects/e.o .objects/f.o .objects/g.o .objects/h.o
ar: .objects/b.o: No such file or directory
ar: .objects/c.o: No such file or directory
ar: .objects/d.o: No such file or directory
ar: .objects/e.o: No such file or directory
ar: .objects/f.o: No such file or directory
ar: .objects/g.o: No such file or directory
ar: .objects/h.o: No such file or directory
make: *** [.results/libalphabet.a] Error 1

3.80


% /usr/bin/make --version
GNU Make 3.80
Copyright (C) 2002  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

% /usr/bin/make -r -R clobber
rm -f .depends/a.d .depends/b.d .depends/c.d .depends/d.d .depends/e.d
.depends/f.d .depends/g.d .depends/h.d
rm -f .objects/a.o .objects/b.o .objects/c.o .objects/d.o .objects/e.o
.objects/f.o .objects/g.o .objects/h.o
rm -f .results/libalphabet.a
rm -rf .objects/
rm -rf .depends/
rm -rf .results/

% /usr/bin/make -r -R 
mkdir -p .depends
mkdir -p .objects
gcc -g -O1 -MD -MP -MF .depends/a.d -c -o .objects/a.o a.c
gcc -g -O1 -MD -MP -MF .depends/b.d -c -o .objects/b.o b.c
gcc -g -O1 -MD -MP -MF .depends/c.d -c -o .objects/c.o c.c
gcc -g -O1 -MD -MP -MF .depends/d.d -c -o .objects/d.o d.c
gcc -g -O1 -MD -MP -MF .depends/e.d -c -o .objects/e.o e.c
gcc -g -O1 -MD -MP -MF .depends/f.d -c -o .objects/f.o f.c
gcc -g -O1 -MD -MP -MF .de

[bug #17873] .NOTPARALLEL enhancements

[anonymous]

Follow-up Comment #9, bug #17873 (project make):

Agree with you

--
Online 

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #19113] cannot self-remake makefile starting with './'

[anonymous]

Follow-up Comment #1, bug #19113 (project make):

Thank's

-
Online 

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #18622] regression cannot turn off implicit rules for %.c and %.tex in 3.81

[anonymous]

Follow-up Comment #1, bug #18622 (project make):

Thank's

--
on line 

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #18124] make-3.81 isn't parallel build safe

[anonymous]

Follow-up Comment #3, bug #18124 (project make):

Thank you!

---
online 

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

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

[anonymous]

Follow-up Comment #24, bug #15919 (project make):

This bug affects a patch for GCC that would provide automated makefile
dependencies.  It causes a lockup for "make -j2" and we had to revert the
patch.  Getting this patch in a stable release would be a very good thing...

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #17873] .NOTPARALLEL enhancements

[anonymous]

Follow-up Comment #13, bug #17873 (project make):

[url=http://www.VeromaxXx.com]Buy Kamagra[/url]

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #17873] .NOTPARALLEL enhancements

[anonymous]

Follow-up Comment #15, bug #17873 (project make):

Nope, not hax0red, it just allows anyone to add comments without logging in. 
You only have to enter a 

Presumably there haven't been enough serious enough spam attacks yet to make
anyone want to do anything about it, so bug maintainers are just deleting the
occasional ones that show up as they come across them.

  cheers,
DaveK



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #17873] .NOTPARALLEL enhancements

[anonymous]

Follow-up Comment #16, bug #17873 (project make):

..oops, went too soon.  I was going to say "only have to enter a basic
plaintext captcha to posta anon, so it could be easily defeated either
manually or programmatically - I think it's always 421.

  (DaveK again)

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #17873] .NOTPARALLEL enhancements

[anonymous]

Follow-up Comment #17, bug #17873 (project make):

nklnlk


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #17873] .NOTPARALLEL enhancements

[anonymous]

Follow-up Comment #18, bug #17873 (project make):

..oops, went too soon. I was going to say "only have to enter a basic
plaintext captcha to posta anon.
http://tube8.wikidot.com
http://www.zootube-beastiality.com
http://haporn.wikidot.com
So it could be easily defeated either manually or programmatically - I think
it's always 421. 
http://pornhub.wikidot.com
http://pornhub.ning.com
http://zootube-sex.wikidot.com
Presumably there haven't been enough serious enough spam attacks yet to make
anyone want to do anything about it, so bug maintainers are just deleting the
occasional ones that show up as they come across them.
http://zootube-sex.us
http://redtube.wikidot.com
http://00usa.net
Because even the most correct dependencies fail to account for
programs/scripts that use conflicting temporary/auxiliary files.
http://myfreepaysite.wikidot.com
http://tube8a.ning.com
http://tube8x.ning.com
 cheers,
DaveK 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #17873] .NOTPARALLEL enhancements

[anonymous]

Follow-up Comment #20, bug #17873 (project make):

When you start/finnish working on this, please update the bug fields
accordingly to enable us to track the progress. Thanks in advance for your
efforts - http://free-credit-report.wikidot.com
and http://bad-credit-loans.wikidot.com
and http://credit-report.wikidot.com
and http://buy-xanax-without-prescription.wikidot.com
and even http://cash-advance-x.wikidot.com

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #21854] Dependency to a -l to be made in a not yet existing directory doesn't match(?)

[anonymous]

Follow-up Comment #1, bug #21854 (project make):

You can bypass this easily by adding another rule like:

-lfunny_name: path_to_library_where_to_get_library.so
#rules to place library where you want it

This dependency will be evaluated only when make does not resolve
-lfunny_name by itself, i.e. the library does not exist in your scanned
directory.

I use such technique in my Makefiles for about a year now and see no problems
with that.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #17873] .NOTPARALLEL enhancements

[anonymous]

Follow-up Comment #21, bug #17873 (project make):

http://myfreepaysite.wikidot.com

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #22434] Consider a dependancy as target file and try to make the file

[anonymous]

Follow-up Comment #5, bug #22434 (project make):

Sorry for the poor description. I will try to explain. 
http://myfreepaysite.wikidot.com

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #17873] .NOTPARALLEL enhancements

[anonymous]

Follow-up Comment #23, bug #17873 (project make):

http://satanis.org
http://amazingjapan.net
http://00usa.net
http://bestsextour.com
http://stopaddiction.us
http://zootubesex-x.com

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #17873] .NOTPARALLEL enhancements

[anonymous]

Follow-up Comment #24, bug #17873 (project make):

http://freeonlinecreditreport.ning.com
http://creditreportz.ning.com
http://watchmoviesonline.ning.com
http://buyxanaxx.ipbfree.com
http://watchmoviesonline.ipbfree.com
http://cheaptramadoll.ning.com
http://tramadolec.ning.com
http://tramadolhere.ning.com
http://freecreditreportx.ipbfree.com


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #17873] .NOTPARALLEL enhancements

[anonymous]

Follow-up Comment #26, bug #17873 (project make):

Sleeping Pills Dosade 
Sleeping pills list 
online sleeping pills 
sleeping pils 
herbal sleeping pills 
sleep pills 
zoloft paxil 
paxil side effect 
paxil anxiety 
order paxil 
paxil online 
paxil depression 
cheap paxil 
generic ambien usa 
ambien mexico co uk 
ambien canada 
ambien usa 
ambien pills 
easy order ambien 
buy ambien 
purchase ambien 

vardenafil levitra online 
generic levitra online 
discount levitra online 
cheap levitra online 
levitra online order 
order viagra online 
acheter viagra 
kaufen viagra 
comprare viagra 
viagra online california 
viagra online delaware 
viagra online arkansas 
viagra online connecticut 
viagra online arizona 
viagra online florida 
viagra online colorado 
viagra online georgia 
viagra online alaska 
viagra online alabama 
viagra online maryland 
viagra online hawaii 
viagra online idaho 
viagra online kentucky 
viagra online illinois 
viagra online kansas 
viagra online louisiana 
viagra online iowa 
viagra online indiana 
viagra online maine 
viagra online new hampshire

viagra online new jersey 
viagra online nevada 
viagra online massachusetts

viagra online missouri 
viagra online minnesota 
viagra online nebraska 
viagra online montana 
viagra online mississippi 
viagra online michigan 
viagra online oklahoma 
viagra online oregon 
viagra online rhode island 
viagra online ohio 
viagra online pennsylvania 
viagra online north dakota 
viagra online north carolina

viagra online south carolina

viagra online new york 
viagra online new mexico 
viagra online wyoming 
viagra online tennessee 
viagra online west virginia

viagra online utah 
viagra online virginia 
viagra online texas 
viagra online vermont 
v

[bug #23210] target/dependants with equal mtime

[anonymous]

URL:
  

 Summary: target/dependants with equal mtime
 Project: make
Submitted by: None
Submitted on: Thursday 05/08/2008 at 18:46 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: POSIX-Based
   Fixed Release: None

___

Details:

Consider a set of Makefiles like the following:

- - - - dir1/Makefile - - - -
../libfoo.a: foo1.o
ar rcs ../libfoo.a foo1.o

foo1.o: foo1.c
cc -c foo1.c
- - - - - - - - - - - - - - - -

- - - - dir2/Makefile - - - -
../libfoo.a: foo2.o
ar rcs ../libfoo.a foo2.o

foo2.o: foo2.c
cc -c foo2.c
- - - - - - - - - - - - - - - -

where a "make" is executed sequentially in the
two directories.  My expectation is that foo1.o
will be built and ar'd into libfoo.a, then foo2.o
will be built and also ar'd into libfoo.a.

But what actually happens is that foo1.o is indeed
built and ar'd into libfoo.a and foo2.o is also built,
but then the date on libfoo.a is compared to the date
on foo2.o and due to the coarse granularity of the
mtime, foo2.o is observed to have the same date as
libfoo.a rather than being newer, and it is not ar'd
into libfoo.a.

Is this a bug in make, or is the above example an
illigitimate use of make?

If it is considered a bug in make, here's a simpler
more artificial example that demonstrates the same
issue:

- - - - Makefile - - - -
a: b
touch a
b:
touch b
- - - - - - - - - - - - -

And here is a command which demonstrates behavior
I think is erroneous:

% rm -f b ; touch a ; make a

In this example I would expect it to see that "b"
is not there, and determine that it must make "b"
as well as update "a".  Thus I expect to see
output
  touch b
  touch a
But instead on a system where the fstat gives an
mtime with granularity in seconds which seems
common, the above command usually results in
only
  touch b
being executed.  Apparently it looks at the
dependancy list for "a", decides it needs to
make "b", does so, looks at the date on "b"
after it has made it, then decides that since
"b" is not strictly newer than "a" based on
the date with 1-second granularity it won't
update "a".





___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #23210] target/dependants with equal mtime

[anonymous]

Follow-up Comment #1, bug #23210 (project make):

For this makefile:

> ../libfoo.a: foo1.o
>ar rcs ../libfoo.a foo1.o

make is doing what you told it to; the problem is that the makefile doesn't
capture your intent.  That makefile says "add or update the foo1.o member of
../libfoo.a if _and_only_if_ the foo1.o file is newer
_than_the_archive_itself_".  That's wrong: the foo1.o member should be updated
if the foo1.o file is newer than the _member_in_the_archive_.  Using the
archive member syntax solves that:

../libfoo.a(foo1.o): foo1.o
ar rcs ../libfoo.a foo1.o

(Of course, archive members targets have their own issue with parallel
builds, but that at least can be handled with .NOTPARALLEL)


Philip Guenther


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #23210] target/dependants with equal mtime

[anonymous]

Follow-up Comment #2, bug #23210 (project make):

I can see your point.  Your change essentially makes the target in the
"target: source" rule more specific thus turning foo2.o into an exhaustive
list of things the new more-specified target depends on.  Previously one
Makefile said libfoo.a depends on foo1.o, and another said it depends on
foo2.o, and that allowed the target to get updated before 100% of the things
it depended on were created.

But I still find the behavior odd, because in the original example foo2.o
_is_ newer than libfoo.a for a reasonably intuitive sense of the word "newer":
it was created chronologically after the most recent update to libfoo.a.  It's
only the luck of how quickly the operations happen and the granularity of the
filesystem's mtime that determines whether the second foo2.o will be ar'd or
not.

I do like the facility you pointed out which allows a subset of an archive to
be used as a target though, since it's quite natural to update an archive
piecemeal and that wouldn't be possible without such a facility.  It seems
like a pretty specialized solution, although I'll admit I'm not coming up with
many other examples offhand where piecemeal updates are as common/natural as
an archive (maybe a .tar file).


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #23273] Please include xkcd easteregg

[anonymous]

URL:
  

 Summary: Please include xkcd easteregg
 Project: make
Submitted by: None
Submitted on: Samstag 17.05.2008 um 10:09 UTC
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: Any
   Fixed Release: None

___

Details:

Hi,

this might be an odd request, but please consider it nevertheless.

There is a very popular web comic involving the make command:
http://xkcd.com/149/

It would not be useful, but entertaining, if the make command  would behave
like this. So I’m proposing the following behaviour:

If make is run with the arguments "me a sandwich", and there is no target
called "me", the error message is replaced by "What? Make it yourself.", if
SUDO_COMMAND is unset, or "Okay." if that variable is set.

I think this does not distrub any operations, as it only modifies the error
message. If there is a target called "me", make should behave usual.

If you would be willing to include such a "feature", I’ll provide a patch.

Thanks,
Joachim




___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #17614] Clock Slew < 1 sec.

[anonymous]

Follow-up Comment #2, bug #17614 (project make):

make[3]: Warning: File `./libPPC85XXgnuAPPtelcoImmib.a' has modification time
--->>0.03 s<<--- in the future

That's three one *hundredths* of one second. Some systems don't allow NTP to
slew their clock, only step it, and in any case, 30 milliseconds is getting
down into trans-router packet transit times, and NTP-startup time skews.

What's more, the NTP daemon's default step threshold is 128ms, or 0.128
seconds, about 43 times larger than the time skew complained about above.

There has to be a cutoff somewhere, even if it's not 1 second, otherwise why
not use (*timespec_t)x->tv_nsec and complain about a file's timestamp being
.1 seconds in the future?

How about 0.15 seconds, to exceed the NTP step threshold by 22 milliseconds?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #17873] .NOTPARALLEL enhancements

[anonymous]

Follow-up Comment #28, bug #17873 (project make):

http://groups.google.us/group/animal-sex-tube-2008
http://groups.google.us/group/free-animal-sex-tube
http://groups.google.us/group/shockingtube
http://groups.google.us/group/free-animal-porn-tubex
http://groups.google.us/group/free-animal-porn-tubes
http://groups.google.us/group/animals-x
http://groups.google.us/group/zoo-tube-365-com
http://groups.google.us/group/free-sextube-xx

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #17873] .NOTPARALLEL enhancements

[anonymous]

Follow-up Comment #29, bug #17873 (project make):

Best sites from google.de :
1)
http://www.google.de/notebook/public/04608191802079853396/BDShxQwoQqI2u9aMj
2)
http://www.google.de/notebook/public/14811194029080121230/BDShxQwoQ-K6u9aMj
3)
http://www.google.de/notebook/public/04608191802079853396/BDSIKQgoQwYS79aMj
4)
http://www.google.de/notebook/public/04608191802079853396/BDQouQwoQgaq79aMj
5)
http://www.google.de/notebook/public/04608191802079853396/BDQcKQgoQ4c679aMj
6)
http://www.google.de/notebook/public/04608191802079853396/BDShxQwoQ-fO79aMj
7)
http://www.google.de/notebook/public/13061649652563958978/BDSHDQwoQgKq89aMj
8)
http://www.google.de/notebook/public/13061649652563958978/BDQcKQgoQhc289aMj
9)
http://www.google.de/notebook/public/13061649652563958978/BDSHDQwoQ5fG89aMj
10)
http://www.google.de/notebook/public/16826695713444040349/BDQGMQgoQva299aMj
11)
http://www.google.de/notebook/public/16826695713444040349/BDQcKQgoQ4dG99aMj
12)
http://www.google.de/notebook/public/16826695713444040349/BDQ2NQgoQv_W99aMj
13)
http://www.google.de/notebook/public/14811194029080121230/BDShxQwoQsJm-9aMj
14)
http://www.google.de/notebook/public/14811194029080121230/BDQGMQgoQ5r2-9aMj
15)
http://www.google.de/notebook/public/14811194029080121230/BDSIKQgoQgea-9aMj
16)
http://www.google.de/notebook/public/14811194029080121230/BDQaSQgoQo4m_9aMj
17)
http://www.google.de/notebook/public/17317152843759546979/BDSMKQgoQuK2_9aMj
18)
http://www.google.de/notebook/public/17317152843759546979/BDQcKQgoQyNC_9aMj
19)
http://www.google.de/notebook/public/17317152843759546979/BDShxQwoQpfO_9aMj
20)
http://www.google.de/notebook/public/17317152843759546979/BDShxQwoQ9JjA9aMj
21)
http://www.google.de/notebook/public/03229453723828530204/BDShxQwoQ-LvA9aMj
22 
http://www.google.de/notebook/public/03229453723828530204/BDQouQwoQ8N7A9aMj
23)
http://www.google.de/notebook/public/03229453723828530204/BDQaSQgoQzITB9aMj
24)
http://www.google.de/notebook/public/03229453723828530204/BDShxQwoQw6rB9aMj
25)
http://www.google.de/notebook/public/06400866979459256914/BDQ2NQgoQ_dTB9aMj
26)
http://www.google.de/notebook/public/06400866979459256914/BDShxQwoQyPjB9aMj
27)
http://www.google.de/notebook/public/06400866979459256914/BDQcKQgoQ1JzC9aMj
28)
http://www.google.de/notebook/public/06400866979459256914/BDQ2NQgoQ5bvC9aMj
29)
http://www.google.de/notebook/public/01766436141041937324/BDShxQwoQ7t_C9aMj
30)
http://www.google.de/notebook/public/01766436141041937324/BDSMKQgoQqIrD9aMj
31)
http://www.google.de/notebook/public/01766436141041937324/BDSHDQwoQt7DD9aMj
32)
http://www.google.de/notebook/public/01766436141041937324/BDSMKQgoQ_dXD9aMj
33)
http://www.google.de/notebook/public/03054172070810390609/BDQ2NQgoQ-fvD9aMj
34)
http://www.google.de/notebook/public/03054172070810390609/BDSIKQgoQwJjE9aMj
35)
http://www.google.de/notebook/public/03054172070810390609/BDQcKQgoQ67zE9aMj
36)
http://www.google.de/notebook/public/03054172070810390609/BDQouQwoQkOTE9aMj
37)
http://www.google.de/notebook/public/11647051931541063004/BDQ2NQgoQp4rF9aMj
38)
http://www.google.de/notebook/public/11647051931541063004/BDQcKQgoQzbTF9aMj
39)
http://www.google.de/notebook/public/11647051931541063004/BDSMKQgoQx9vF9aMj
40)
http://www.google.de/notebook/public/11647051931541063004/BDSIKQgoQp4LG9aMj
41)
http://www.google.de/notebook/public/18236042230916225380/BDQcKQgoQ4J3G9aMj
42)
http://www.google.de/notebook/public/18236042230916225380/BDSHDQwoQ68DG9aMj
43)
http://www.google.de/notebook/public/18236042230916225380/BDQcKQgoQ8uLG9aMj
44)
http://www.google.de/notebook/public/18236042230916225380/BDSMKQgoQ1oXH9aMj
45)
http://www.google.de/notebook/public/00355309926142456421/BDSIKQgoQ06nH9aMj
46)
http://www.google.de/notebook/public/00355309926142456421/BDQouQwoQqdDH9aMj
47)
http://www.google.de/notebook/public/00355309926142456421/BDQaSQgoQ1_TH9aMj
48)
http://www.google.de/notebook/public/00355309926142456421/BDSHDQwoQj5nI9aMj
49)
http://www.google.de/notebook/public/04608191802079853396/BDSHDQwoQ__LP9aMj
50)
http://www.google.de/notebook/public/13061649652563958978/BDShxQwoQn5jQ9aMj

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #23468] end-of-line backslashes fails with perl (Cygwin, although I strongly believe it's general problem)

[anonymous]

URL:
  

 Summary: end-of-line backslashes fails with perl  (Cygwin,
although I strongly believe it's general problem)
 Project: make
Submitted by: None
Submitted on: Tuesday 06/03/2008 at 03:47 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: Any
   Fixed Release: None

___

Details:

Makefile that produce this bug is attached.
There are two targets in the makefile.  These two targets should be
identical, except that one of them is using backslashes to break lines.
As said in the summary (title), the target with backslashes fails.

Although this is seen in Cygwin, I believe it is a general issue.
An evidence is:
I did try to do both unix2dos, and dos2unix on Makefile. Same results.

Make v3.80 works well, but Make v3.81 fails on the backslash target.

See the attached Makefile (and input file) for detail.




___

File Attachments:


---
Date: Tuesday 06/03/2008 at 03:47 UTC  Name: Makefile  Size: 1kB   By: None


---
Date: Tuesday 06/03/2008 at 03:47 UTC  Name: input.txt  Size: 71B   By: None



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #23468] end-of-line backslashes fails with perl (Cygwin, although I strongly believe it's general problem)

[anonymous]

Follow-up Comment #1, bug #23468 (project make):

Look in the NEWS file:

* WARNING: Backward-incompatibility!
  In order to comply with POSIX, the way in which GNU make processes
  backslash-newline sequences in command strings has changed.  If your
  makefiles use backslash-newline sequences inside of single-quoted
  strings in command scripts you will be impacted by this change.  See
  the GNU make manual subsection "Splitting Command Lines" (node
  "Splitting Lines"), in section "Command Syntax", chapter "Writing the
  Commands in Rules", for details.

This is a feature, not a bug.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #17873] .NOTPARALLEL enhancements

[anonymous]

Follow-up Comment #30, bug #17873 (project make):

asdwq

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #17873] .NOTPARALLEL enhancements

[anonymous]

Follow-up Comment #32, bug #17873 (project make):

> What am I missing?

The chance to buy cheap viagra?  ;-)


scnr

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

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

[anonymous]

Additional Item Attachment, bug #18963 (project make):

File name: get_php_80x15.png  Size:3 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #20133] 'make -p' always uses ':=' for pattern-specific variable assignments

[anonymous]

Additional Item Attachment, bug #20133 (project make):

File name: get_php_80x15_2.pngSize:3 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #18622] regression cannot turn off implicit rules for %.c and %.tex in 3.81

[anonymous]

Additional Item Attachment, bug #18622 (project make):

File name: feed_atom03_80x15.png  Size:3 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #17873] .NOTPARALLEL enhancements

[anonymous]

Follow-up Comment #33, bug #17873 (project make):

since the dependencies are fake, problems arise easily.
http://without-prescription-no.com ,  and some makefiles may be using it, so
we'd have to use some other special target.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #18396] stack size setrlimit call interacts badly with Solaris/x86 kernel bug

[anonymous]

Follow-up Comment #4, bug #18396 (project make):

I experienced an converse effect.  I could run a program (kpdf) from shell,
but it would crash if started from make.

I used a large hard limit (~1GB) for the stack size and around 100MB as soft
limit (used it for a scientific app).  My machine has 2 GB Ram.

kpdf fails to start a helper thread with this message:

  QThread::start: thread creation error: Cannot allocate memory

The problem seems to be that make ups the soft limit to the hard limit and
runs its childs with this setting.

One can certainly argue, that kpdf behaves disadvantageous, however, make
should not change the user's specified environment.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #17873] .NOTPARALLEL enhancements

[anonymous]

Follow-up Comment #34, bug #17873 (project make):

http://zoofucking.wiki.zoho.com/zoo-fucking.html
http://zoofucking.wiki.zoho.com/zootube365.html
http://zoofucking.wiki.zoho.com/Beastiality-video.html
http://zoofucking.wiki.zoho.com/zootube-com.html


http://zoo-fucking.wikidot.com
http://zootube365.wikidot.com
http://zootube-com.wikidot.com
http://zootube-beastiality.wikidot.com
http://beastiality-video.wikidot.com
http://animal-porn-tube.wikidot.com
http://glam0ur.wikidot.com
http://novoporn.wikidot.com
http://hentaicrack.wikidot.com
http://24porn7.wikidot.com
http://nonknonk.wikidot.com
http://enwhore.wikidot.com
http://wunbuck.wikidot.com
http://assdumper.wikidot.com
http://spankwire.wikidot.com
http://sextube-videos.wikidot.com
http://sextubes.wikidot.com
http://xxxtube.wikidot.com
http://dreammovies.wikidot.com
http://qporno.wikidot.com
http://sunporno.wikidot.com
http://keezmovies.wikidot.com
http://freeiq.com/zoo1?fullbio=1
http://freeiq.com/zootube365com?fullbio=1
http://freeiq.com/zootubecom?fullbio=1
http://freeiq.com/spankwirevideos?fullbio=1
http://freeiq.com/pinktorrentcom?fullbio=1
http://freeiq.com/pimpbus?fullbio=1
http://freeiq.com/needbangcom?fullbio=1
http://freeiq.com/masterwankercom?fullbio=1
http://freeiq.com/needtwatcom?fullbio=1
http://freeiq.com/assdumper?fullbio=1
http://freeiq.com/wunbuckcom?fullbio=1
http://freeiq.com/enwhorecom?fullbio=1
http://freeiq.com/nonknonk?fullbio=1
http://freeiq.com/24porn7com?fullbio=1
http://freeiq.com/sexmummycom?fullbio=1
http://freeiq.com/origintvfree?fullbio=1
http://freeiq.com/hmvideosonline?fullbio=1
http://freeiq.com/amateurpornteensvideo?fullbio=1
http://freeiq.com/eroxiacom?fullbio=1
http://freeiq.com/wetpussygamescom?fullbio=1
http://freeiq.com/hornygamercom?fullbio=1
http://freeiq.com/hentaicrackcom?fullbio=1
http://freeiq.com/novoporncom?fullbio=1
http://freeiq.com/glam0urcom?fullbio=1
http://freeiq.com/underagegirls?fullbio=1

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #23922] On XP 64 with sh.exe installed in "Program Files (x86)" gmake generates a stack overflow exception.

[anonymous]

URL:
  

 Summary: On XP 64 with sh.exe installed in "Program Files
(x86)" gmake generates a stack overflow exception.
 Project: make
Submitted by: None
Submitted on: Thursday 24/07/08 at 09:21 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: None
   Fixed Release: None

___

Details:

This seems to be a combination of the "()"s in the path for sh, and using
output redirection in a rule. Our makefile includes the following rule:

${UNIAV_H}: mkuniav.c quadav.h
mk_cc $<
mk_lnk ${call getexe, $<} ${call getobj, $<}
mkuniav.exe > ${UNIAV_H}

The redirection on the last line of the rule causes gmake to enter an
infinite loop generating the command line to execute. Removing the ">" or
moving sh.exe to a directory without "()"s in works around the problem.






___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #23928] Add MAKEFILE variable

[anonymous]

URL:
  

 Summary: Add MAKEFILE variable
 Project: make
Submitted by: None
Submitted on: Thursday 07/24/2008 at 13:35 UTC
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: None
   Fixed Release: None

___

Details:

It is often useful to recursively call the current makefile as
part of a rule.  Sometimes rules are included from a different file.  The
included file may not know the name of the make file used to start the make
process.  Having a MAKEFILE variable would solve this.

File rules.mk:
---
foo:
   make -f $(MAKEFILE) bar

bar:
   echo hello


File GNUmakefile:
-
include rules.mk

File Test.mk:
-
include rules.mk




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #17873] .NOTPARALLEL enhancements

[anonymous]

Follow-up Comment #35, bug #17873 (project make):

I have same problem with - 
http://opensource-news.net/
http://swixx.net/
http://slurix.net/
http://med247.us/
http://free-exotic-stories.net/
http://pornhubz.com/
http://bestsextour.com/
http://stopaddiction.us/
http://amazingjapan.net/

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #23928] Add MAKEFILE variable

[anonymous]

Follow-up Comment #3, bug #23928 (project make):

Icarus Sparry wrote:
> You probably want lastword, rather than firstword.

Nope.  To quote the original request:

> It is often useful to recursively call the current makefile
> as part of a rule. Sometimes rules are included from a
> different file. The included file may not know the name of
> the make file used to start the make process.

The request was for the name of "the make file used to start the make
process", which would be $(firstword ${MAKEFILE_LIST}).

(The use of the phrase "current makefile" is slightly ambiguous, but I think
the last sentence makes it clear that it is meant to refer to the makefile
that started the whole deal.)


BTW, $(lastword ${MAKEFILE_LIST}) is _not_ always the makefile being parsed
at that moment, particularly when there's an 'include' directive earlier in
the makefile.  There's in fact no 100% general and reliable way to get the
name of the file that's being parsed.


Philip Guenther


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #17873] .NOTPARALLEL enhancements

[anonymous]

Follow-up Comment #36, bug #17873 (project make):

just free 

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #23986] make doesnt make cookies

[anonymous]

URL:
  

 Summary: make doesnt make cookies
 Project: make
Submitted by: None
Submitted on: Saturday 08/02/2008 at 21:25 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: POSIX-Based
   Fixed Release: None

___

Details:

[EMAIL PROTECTED] ~ make cookies
make: *** No rule to make target `cookies'.  Stop.


crap




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #17873] .NOTPARALLEL enhancements

[anonymous]

Follow-up Comment #37, bug #17873 (project make):

  Below the waist https://myweb.liu.edu/sonic/viewtopic.php?p=7342 slightly
flared hips hinted at approaching womanhood and
https://myweb.liu.edu/sonic/viewtopic.php?p=7342 long slender legs tapered up
to a beautiful little heart shaped arse.
  It was elegant and classy, which was just perfect for her; the velvety
material would caress https://myweb.liu.edu/sonic/viewtopic.php?p=7348
curves.
 Tammy reached down and wrapped
https://myweb.liu.edu/sonic/viewtopic.php?p=7369 warm hand around my shaft and
slowly began stroking it.
  He asked Tammy where https://myweb.liu.edu/sonic/viewtopic.php?p=7383 purse
was, and demanded my wallet, which
https://myweb.liu.edu/sonic/viewtopic.php?p=7383 gave him.
 After a few minutes, Mandy looked up into
http://www.pspvideo9.com/forums/viewtopic.php?p=268556 face, and 
http://www.pspvideo9.com/forums/viewtopic.php?p=268556  saw tears streaming
down http://www.pspvideo9.com/forums/viewtopic.php?p=268556 cheeks.
 Mandy batted http://www.pspvideo9.com/forums/viewtopic.php?p=268559 eyes and
purred, “Well, http://www.pspvideo9.com/forums/viewtopic.php?p=268559 for
one cannot wait to show http://www.pspvideo9.com/forums/viewtopic.php?p=268559
what I’d like to buy when
http://www.pspvideo9.com/forums/viewtopic.php?p=268559 go shopping.
  He quickly zipped http://www.pspvideo9.com/forums/viewtopic.php?p=268563
pants up and hurried toward the living room.
  As the memory of Rebecca flashed through
http://www.pspvideo9.com/forums/viewtopic.php?p=268596 head,
http://www.pspvideo9.com/forums/viewtopic.php?p=268596 shivered.
  His heart skipped a beat; http://www.wikio.com/user/redtube/bio whole body
trembled with desire---no with love, as http://www.wikio.com/user/redtube/bio
just realized that http://www.wikio.com/user/redtube/bio too loved Mandy.
  http://www.wikio.com/user/tube8/bio watched
http://www.wikio.com/user/tube8/bio go and slip behind some chairs and then
http://www.wikio.com/user/tube8/bio was gone leaving
http://www.wikio.com/user/tube8/bio slightly puzzled as my view had been
slightly obscured at the vital moment.
 Mandy’s fingers searched for http://www.wikio.com/user/pornhub/bio cock as
http://www.wikio.com/user/pornhub/bio tantalizes
http://www.wikio.com/user/pornhub/bio pussy.
 ‘Mmmm, that’s nice’ http://redtube.u.yuku.com/ said and moved closer
to me, moving http://redtube.u.yuku.com/ hand on to my thigh and imitating my
movements.
 As  http://tube8.u.yuku.com/  cooked the steaks on the gas grill, Mandy
began to prepare, a salad, steamed broccoli, and French bread.
  On the final go,  http://pornhub.u.yuku.com/  was to hide again and this
time http://pornhub.u.yuku.com/ searched pretty close to the youngsters.
  She fought back more tears, because http://zootube.u.yuku.com/ really did
miss http://zootube.u.yuku.com/ mother.
 She kissed http://youporn.u.yuku.com/ cheek and squealed, “
http://youporn.u.yuku.com/ , I’d love to.
 ” http://youpornos.u.yuku.com/ 's cock hits bottom and
http://youpornos.u.yuku.com/ trembled while watching
http://youpornos.u.yuku.com/ move herself all the way up just holding
http://youpornos.u.yuku.com/ cock head inside her.
 ”She smirked and said, “Well if http://yuvutu.u.yuku.com/ does guess
http://yuvutu.u.yuku.com/ can do some more fucking huh!”
http://yuvutu.u.yuku.com/ ’s eyes twinkled with lust and
http://yuvutu.u.yuku.com/ lay on http://yuvutu.u.yuku.com/ back.
  The tops of http://youjizz.u.yuku.com/ milk filled tits were barely
contained in the bra cups.
 Never in http://pornotube.u.yuku.com/ wildest dreams did
http://pornotube.u.yuku.com/ think, after Rebecca died, would ever find love
again.
  “Are http://xtube.u.yuku.com/ ready for http://xtube.u.yuku.com/
honey?”Mandy licks http://xtube.u.yuku.com/ lips, tries to remain calm and
replies, “Sure Dad, come on in.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #17873] .NOTPARALLEL enhancements

[anonymous]

Follow-up Comment #38, bug #17873 (project make):

Gift Baskets 
Flowers 
Spring Flowers 
Soft Toys 
Acne Treatment 
Alternative Medicine 
Anti Aging 
Health and Beauty 
Cancer symptoms and risks 
Great Fishing 
Muscle building 
Fashion world 
Diseases and Conditions 
Exercise and Meditations 



blood drug test 
employment drug testing 
hair drug test 
pass a drug test 
random drug testing 
saliva drug test 
urine drug test 
workplace drug testing 
employee drug testing 
marijuana drug test 
home drug test kits 
drug testing kits 


mp3 downloads 
download mp3 
buy mp3 music 
mp3 music downloads 
music mp3 download 
mp3 audio download 
movies dvd dowload 
pass a drug test 
gift baskets 

kazakh xml manual 
xml manual 

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #24164] Improper Evaluation of Multiple Target rules with Static Patterns

[anonymous]

URL:
  

 Summary: Improper Evaluation of Multiple Target rules with
Static Patterns
 Project: make
Submitted by: None
Submitted on: Sat 30 Aug 2008 01:16:23 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: Any
   Fixed Release: None

___

Details:

I apologize in advance if this is a direct duplicate - I saw some bugs
addressing the same general facility, but all seemed to deal with a more
complex situation than the one I'm going to present. I do, however, suspect
that they stem from the issue I'm going to attempt to demonstrate in the
simplest case.

The documentation regarding rules with multiple targets (4.10 in the 'info'
page) states that "A rule with multiple targets is equivalent to writing many
rules, each with one target, and all identical aside from that." This seems
intuitive, as the "Multiple Targets" facility is a means of consolidating
common dependencies and operations into a single rule, saving space and
eliminating duplication of code.

However, in the case that the "multiple targets" contain static patterns,
they seem to be evaluated improperly. If the static pattern is matched against
one of the targets, other targets declared in the same "multiple targets" rule
with the same static pattern will be considered by that invocation of 'make'
to be satisfied.

To demonstrate this, consider the following Makefiles (included as
attachments):

=== 'Makefile.problem' ===
a.% b.%:
@echo "$@: Rule Invoked with '$*'!"

=== 'Makefile.control' ===
a.%:
@echo "$@: Rule Invoked with '$*'!"

b.%:
@echo "$@: Rule Invoked with '$*'!"

These Makefiles declare two rules, 'a.%' and 'b.%', both with the same
associated action. 'Makefile.problem' consolidates these into a single
"multiple target" rule, while 'Makefile.control' separates them out into two
identical rules. However, invoking 'make' on these different files will
produce noticeably different results:

> make -f Makefile.control a.0 b.0 b.1
a.0: Rule Invoked with '0'!
b.0: Rule Invoked with '0'!
b.1: Rule Invoked with '1'!

> make -f Makefile.problem a.0 b.0 b.1
a.0: Rule Invoked with '0'!
make: Nothing to be done for `b.0'.
b.1: Rule Invoked with '1'!

Continuing with this, any target provided on the command-line (and, in more
complex Makefiles, named in dependencies) whose static pattern was matched by
a _different_ already-evaluated target in the same "multiple target"
declaration will be considered, at runtime, to have been met, even though it
wasn't.

I believe intuitively that the behavior of 'Makefile.control' is the correct
one, and that 'Makefile.problem' demonstrates a bug. Otherwise, if this is not
a bug, the documentation in 4.10 is incorrect, as combining the rules into a
"multiple target" is not producing equivalent behavior.

I first encountered this issue on the 'make' packaged with Cygwin. However, I
reproduced it for this report on Linux.

I believe that at least two other bugs listed here are complex manifestations
of the underlying issue demonstrated in this bug:
#19108: http://savannah.gnu.org/bugs/?19108
#12078: http://savannah.gnu.org/bugs/?12078



___

File Attachments:


---
Date: Sat 30 Aug 2008 01:16:23 PM UTC  Name: maketest.tgz  Size: 985B   By:
None
TGZ file demonstrating the possible bug.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #24164] Improper Evaluation of Multiple Target rules with Static Patterns

[anonymous]

Follow-up Comment #1, bug #24164 (project make):

The line about "rules with multiple targets are the same as multiple rules"
doesn't apply to pattern rules.  See section 10.5.1 of the documentation,
which states:

Pattern rules may have more than one target. Unlike normal rules, this does
not act as many different rules with the same prerequisites and recipe. If a
pattern rule has multiple
targets, make knows that the rule’s recipe is responsible for making all of
the targets. The recipe is executed only once to make all the targets. When
searching for a pattern rule to
match a target, the target patterns of a rule other than the one that matches
the target in need of a rule are incidental: make worries only about giving a
recipe and prerequisites to
the file presently in question. However, when this file’s recipe is run,
the other targets are marked as having been updated themselves.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #24164] Improper Evaluation of Multiple Target rules with Static Patterns

[anonymous]

Follow-up Comment #2, bug #24164 (project make):

And furthermore, this is an extremely useful feature.  Without it there is no
other way to express to 'make' a rule where a single recipe generates multiple
output files (and thus needs only be run once to generate them all.)


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #24251] Random error including rebuilt makefiles

[anonymous]

URL:
  

 Summary: Random error including rebuilt makefiles
 Project: make
Submitted by: None
Submitted on: Fri 12 Sep 2008 03:07:19 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: Any
   Fixed Release: None

___

Details:

I'm trying to automatically build (checkout from svn) an included makefile.
The build always succeeds, but the variables set in the included makefile
don't always get set.

I can make it work by building and including a file I don't care for, but
that doesn't seem like a proper solution. (see example)

The same problem occurs with both make 3.79.1 on a Linux machine and make
3.81 on Cygwin/XP machine.

Am I expecting more from make than I should be?

I'm attaching a log showing a trimmed down version of the makefile and the
included makefile along with results showing the inconsistent behaviour.
Unfortunately you won't be able to access my svn repository, but hopefully
you'll be able to recreate the problem some other way.

The $(SUB_CMD_PREFIX) variable defined in $(SUB_MAKE) is always set
successfully, but the $(ECOS_COMMAND_PREFIX) defined in $(ECOS_MAKE) is only
set if $(SUB_MAKE) also needs to be built.
i.e. there seems to be a race condition rather than waiting for the
dependency to complete.

Sorry that this is a duplicate of
http://savannah.gnu.org/support/index.php?106466, but I haven't received any
response there.



___

File Attachments:


---
Date: Fri 12 Sep 2008 03:07:19 PM UTC  Name: make.log  Size: 2kB   By: None
log of session showing makefile, usage results and version info


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #24251] Random error including rebuilt makefiles

[anonymous]

Follow-up Comment #2, bug #24251 (project make):

I don't think this is a duplicate of https://savannah.gnu.org/bugs/?102

This issue isn't about these minor warnings in the output
makefile:10: ecos/include/pkgconf/ecos.mak: No such file or directory
makefile:11: sub/makefile: No such file or directory

This issue is that although make will sometimes build an included makefile it
will then ignore the contents of the included makefile.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #24251] Random error including rebuilt makefiles

[anonymous]

Follow-up Comment #4, bug #24251 (project make):

Thanks Martin for your assistance, adding the semi-colon after the
prerequisite fixes my problem.

I'm not sure I understand the difference, I expect a pre-requisite to be
completely built before it is included, but I'll worry about my lack of
understanding later.

To make administrators,
If the lack of the semi-colon was an error in my makefile, then this bug can
be closed and sorry for the inconvenience.
Even if there is still a bug in make, the severity of this bug can be lowered
since there's a work-around (at least for me).


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #24405] BATCH_MODE_ONLY_SHELL configuration fails with unixy shells

[anonymous]

URL:
  

 Summary: BATCH_MODE_ONLY_SHELL configuration fails with
unixy shells
 Project: make
Submitted by: None
Submitted on: Mon 29 Sep 2008 06:43:03 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: MS Windows
   Fixed Release: None

___

Details:

If make determines that the shell is "unixy", the generated shell script used
to run a rule containing a continuation character will have one too many '\'s.
 For example, the following makefile fails:

all:
echo this is\
a test

because the generated "batch" file used to run the echo command above is:

echo this is\\
a test

This results in two commands being executed (by unixy shells); "echo" and
"a".  Clearly not what was intended.

The attached patch fixes this for me.  Note the "DB (DB_JOBS" line is, of
course, unnecessary but it's invaluable when trying to debug a
BATCH_MODE_ONLY_SHELL configured make.

diff -Naur make-3.81,orig/job.c make-3.81/job.c
--- make-3.81,orig/job.c2006-03-19 19:03:04.0 -0800
+++ make-3.81/job.c 2008-09-27 19:29:03.283931000 -0700
@@ -2733,7 +2733,7 @@
if (PRESERVE_BSNL)
  {
*(ap++) = '\\';
-   *(ap++) = '\\';
+   if (!batch_mode_shell) *(ap++) = '\\';
*(ap++) = '\n';
  }

@@ -2799,6 +2799,9 @@
   fputc ('\n', batch);
   fclose (batch);

+  DB (DB_JOBS, (_("Batch file contents:%s\n\t%s\n"),
+!unixy_shell ? "[EMAIL PROTECTED] off" : "", command_ptr));
+
   /* create argv */
   new_argv = (char **) xmalloc(3 * sizeof (char *));
   if (unixy_shell) {





___

File Attachments:


---
Date: Mon 29 Sep 2008 06:43:03 PM UTC  Name: batch_only_patch.txt  Size: 753B
  By: None
patch to fix reported problem


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #102] Make prints an incorrect error for missing includes

[anonymous]

Follow-up Comment #6, bug #102 (project make):

Do we have an idea to fix this, now?
It is not fatal but really annoying... One workaround may be to make a custom
build script that filters the make output displayed to the user, but that's
not pretty, eh?

Paul: Is the deferring of the error message still a tricky thing to do?

I really was delighted to discover this automatic include-Makefile generation
feature, allowing me nice automatic builds without need for using external
tools like automake/conf.
I would even more be delighted to make not complaining without reason. It
would help convincing my collegue that this "smart" Makefile I wrote really
saves trouble...

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make