[bug #18872] problem colon after drive letter in prerequisite

[Paul D. Smith]

Update of bug #18872 (project make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
   Component Version:None => 3.81   
   Fixed Release:None => CVS

___

Follow-up Comment #2:

Only project admins can change the state of a bug (so you can't re-open it). 
If GCC is generated drive-lettered pathnames in a cygwin environment that is
arguably a bug in GCC on Cygwin; you should report it to either or both GCC
or Cygwin.

However, as Eli points out there has already been a change incorporated to
allow GNU make on Cygwin to handle drive letters properly (for some
definition of properly).  This change will be available in the next release
of 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 #18561] Why backslash line continuation introduce an extra space

[Paul D. Smith]

Update of bug #18561 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

It is by design; in fact it's mandated by the POSIX standard for make, which
states:

> When an escaped  (one preceded by a backslash) is found
> anywhere in the makefile except in a command line, it shall be
> replaced, along with any leading white space on the following
> line, with a single .

Since there is no limit to the length of a physical line in a makefile in GNU
make, I suggest you only break physical lines at whitespace.

___

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 #18641] GNUmake 3.81, $(error ) sometimes unable to stop make process

[Paul D. Smith]

Update of bug #18641 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

I understand that this is an undocumented change in behavior.  However, I
think the new behavior is consistent with the documentation... if the user
suggests that the file does not need to exist for inclusion via "-include"
then it makes sense to me that a failure to build that file should not cause
make to exit.

I think what you really want is a solution to bug #102, so that you can have
mandatory include files but not get any warnings/errors unless they really
can't be built.

___

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 #18641] GNUmake 3.81, $(error ) sometimes unable to stop make process

[Paul D. Smith]

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

The method for auto-generating dependencies described in the GNU make manual
is not the state-of-the-art method.  You should check my website
http://make.paulandlesley.org and look at the advanced auto-dependency
generation description there.  This process was created fro automake by Tom
Tromey and it's much superior to the process in the GNU make manual.  And, it
doesn't suffer from this issue of invalid warnings.

The solution to the problem is just as described in bug #102; the message
about makefiles not being rebuildable would be deferred until after the
makefile has tried to be created and only printed if it couldn't be.  I don't
see any issue with backward compatibility in this.

I took a very quick look at the SF page but there wasn't much there: no
homepage, no docs that I could find, etc.  If you want to discuss it,
probably the help-make@gnu.org mailing list is the best place.  Cheers!

___

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?

[Paul D. Smith]

Update of bug #18963 (project make):

  Item Group: Bug => Documentation  

___

Follow-up Comment #3:

I can see that the documentation is not clear enough.  Perhaps it is trying
to be too stylized, to the point of obscuring its intent.

What the docs should say is: any included makefile (by either "include" or
"-include"), whether it exists or not, will be considered a target and make
will try to update it.  If the makefile exists and the update succeeds (this
includes the case where make does not have any rules to update the makefile),
then it is included.

If the update of the makefile fails then if it was "include"'d,  (although I
think it might be a duplicmake will fail; if it was "-include"'d, make will
ignore the error and continue on.  An update failing can be because the
makefile does not exist and make has no rule to build it; or because the
rules needed to build the makefile (or any of its prerequisites of course)
failed--regardless of whether the makefile exists or not.

I'm changing this to a doc 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 #19015] Initialisation of variable to "ls" and "find" fails with "**missing separator"

[Paul D. Smith]

Update of bug #19015 (project make):

  Status:None => Works for me   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Sorry, but this is not reproducible, and doesn't even make sense.  There's
nothing in the code that would treat any of these values specially.

You must have some issue in your makefile which is causing this; please
attach a sample makefile (don't cut and paste the contents as that will
change them).  Also always provide info on the operating system you're using
and what version it is, etc.

I'm closing this bug for now; if you have more information please add it and
I'll re-open.


___

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 #18995] variable origin changes upon export or unexport

[Paul D. Smith]

Update of bug #18995 (project make):

  Item Group:None => Enhancement
Operating System:None => Any

___

Follow-up Comment #1:

Internally to make, an "undefined" origin means that the variable is not
known to make (when make looks it up in its internal tables, nothing is
found).

Obviously, once you export or unexport a variable, it has to be added to
make's internal tables so make can remember that you marked it as exported or
unexported... so then it's no longer undefined.

I can understand your point, however.  I've marked this as an enhancement
request.  It shouldn't be too difficult to implement: a new origin value for
undefined would need to be added, which is easy... but then all the places
the origin is used would need to be examined to determine if or how they
should react when a variable in this new state is found.

This would also allow us to create a way to "undefine" a variable; currently
once a variable is defined it can never go back to the undefined state 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 #19035] Make recompiles source files eventhough the files are not modified

[Paul D. Smith]

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

Sorry, but there's nothing we can do unless you provide more details, such as
a small example of a makefile that does not work properly for you.

Note that Solaris and HP contain SystemV make; GNU make is not intended to be
a 100% compatible replacement for SystemV make.  GNU make is an implementation
of POSIX-standard make, with many (MANY) extensions.  Just because your
makefile works with Solaris and HP make does not automatically mean it will
work with GNU make--it all depends on what SystemV special features you may
be using, etc.

___

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

[Paul D. Smith]

Update of bug #19122 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

Philip is correct.

As for the difference in clearmake, presumably clearmake has some extra
suffix rules including one for .bin, that GNU make doesn't have.

You can either avoid $* (using $(basename ...) or similar to get rid of the
suffix) or define a suffix for .bin.

___

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 #19183] double-colon pattern rules

[Paul D. Smith]

Update of bug #19183 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

This is not a bug.  Double colon implicit rules have a different meaning than
double-colon explicit rules.  See the section "Match-Anything Pattern Rules"
in the GNU make 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 #19236] Imported variable with trailing backslash messes up make's line parsing in nested evaluations

[Paul D. Smith]

Update of bug #19236 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

I agree this is unpleasant; however I don't see anything make can do about
it.  Eval works by first expanding its argument(s), then evaluating the
result.  In your example, after the expansion of $(Y) make sees:

ifeq (1,1)
B := X\
endif

and there's no possible way that the eval can know that this backslash was
originally contained in the variable A, rather than being written directly by
you.

The only solution to this is for YOU to be more cautious about when you allow
variables to expand.  If you defer the expansion of A so that it's done by the
eval itself instead of being done up front before eval is invoked, then you'll
get the behavior you want; change the definition of Y as follows:

define Y
ifeq (1,1)
B := $$(A)
endif
endef

By using $$(A), it won't expand during the expansion of Y, and eval will see
this:

ifeq (1,1)
B := $(A)
endif

with no backslash... THEN when eval evaluates this IT will expand A and set B
to the right value (X\).  For your "real life" example this would translate
to:

define $(COMP)_CUSTOM_WX_TARGET
ifneq ($(filter bcb%,$(TOOLSET)),)
$(1): export PATH := $(BCCDIR)bin;$$(PATH)
endif
endef

Although, as a general rule, I find it best to defer expansion of ALL
variables other than those that require it (typically as part of a call), so
the above might be more safely written:

define $(COMP)_CUSTOM_WX_TARGET
ifneq ($$(filter bcb%,$$(TOOLSET)),)
$(1): export PATH := $$(BCCDIR)bin;$$(PATH)
endif
endef

I'm closing this for now but if anyone has any ideas on how to make this work
better please add a note or bring it up on the mailing lists.

___

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 #19298] simplify automatic generation of prerequisites example

[Paul D. Smith]

Update of bug #19298 (project make):

Severity:  3 - Normal => 1 - Wish   

___

Follow-up Comment #1:

Unfortunately not every compiler supports these options.  The GNU make manual
does not assume that everyone is using GCC.

Specialized commands for use with GCC could perhaps be added as an
alternative to the generic method.

___

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 #19348] Ineffective configure option --disable-case-insensitive-file-system

[Paul D. Smith]

Update of bug #19348 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => CVS

___

Follow-up Comment #1:

Whoops.  Misunderstanding of how an autoconf macro works.

Fixed in 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 #19309] parallel make issue with archive members

[Paul D. Smith]

Update of bug #19309 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

This is not a bug, and is not related to parallel make; you're using VPATH
incorrectly.  Paul's Third Rule of Makefiles states that you should never use
VPATH to find TARGETS.  VPATH is only usable to find SOURCES.

Read my discussion of VPATH here to learn why your example works the way it
does:

http://make.paulandlesley.org/vpath.html

You're also violating Paul's Second Rule of Makefiles, in this rule:

  .cc.o :
$(CXX) $(CXX_FLAGS) $(INCLUDES) -c -o $(DEST)/$@ $<

ANY time you see a rule where it's constructing a target that is not EXACTLY
"$@", you know the rule is incorrect.  Here you're building "$(DEST)/$@", not
"$@", so your rule is incorrect.

If you rework your example to use VPATH, etc. properly and still see
problems, please file a note with this bug and we can re-open it.

___

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

[Paul D. Smith]

Update of bug #19626 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

This is the way make is documented to work; from the GNU make manual, section
"Variables from the Environment":

   When `make' runs a command script, variables defined in the makefile
are placed into the environment of that command.  This allows you to
pass values to sub-`make' invocations (*note Recursive Use of `make':
Recursion.).  By default, only variables that came from the environment
or the command line are passed to recursive invocations.  You can use
the `export' directive to pass other variables.  *Note Communicating
Variables to a Sub-`make': Variables/Recursion, for full details.


With the single exception of the SHELL variable, all environment variables
are imported as make variables when make starts, and automatically marked as
exported so that when make runs a command their current values will be
exported into the environment of the command.

___

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 #16389] Defaults for Objective-C

[Paul D. Smith]

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

I don't really understand the urgency around this: why not just add the rules
into your makefile if you need them?  The built-in rules are just that:
built-in; they can be added to or removed in makefiles.

I do realize this means that any makefile that uses objective-C needs to be
changed, but the same is true for any number of other languages that make
doesn't provide default rules for.

Further, even if we do change this for the next release of GNU make that
won't be out for some months, then it will be many months more before that
version is considered wide spread (I know of distros that still ship GNU make
3.79.1, and MANY that still use 3.80 more than a year after 3.81 was
released).

And finally, of course, requiring default rules just means makefiles are even
more tightly tied to GNU make (since no other make provides these default
rules as far as I know).

___

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 #19656] strcmpi does not exist on my system, better use strcasecmp instead

[Paul D. Smith]

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

Can you please provide the error messages you received?  As far as I know GNU
make sources don't use strcmpi() except when compiling for non-POSIX systems.

___

Reply to this item at:

  

___
  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.

[Paul D. Smith]

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

Sorry, but you're incorrect about the way original UNIX make worked.  In
fact, every version of make that I'm familiar with does and has always
considered equal timestamps as "up to date".  The POSIX standard for make is
quite clear about this as well:

A target is considered out-of-date if it is older than any of its
prerequisites or if it does not exist.

And also:

The make utility examines time relationships and shall update those derived
files (called targets) that have modified times earlier than the modified
times of the files (called prerequisites) from which they are derived.

It's also incorrect to classify this behavior as a recent change in GNU make;
GNU make has always worked this way.

___

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 #16389] Defaults for Objective-C

[Paul D. Smith]

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

Icarus: I'm sorry you feel frustrated about the situation.  However, I'm not
going to discuss it in bug report comments: that's not appropriate.  If you
want to talk about it you can use one of the public mailing lists, or email
me and/or Boris and/or RMS and/or anyone else you like directly, or even use
the make-alpha list or one of the GNU project mailing lists, depending on the
audience you'd like to contact.

Please keep the bug report comments for discussion on the bugs in the report.
 Thanks!

___

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 #19656] strcmpi does not exist on my system, better use strcasecmp instead

[Paul D. Smith]

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

True; I suppose it was never anticipated that anyone would build with
--enable-case-insensitive-file-system on a POSIX system (because POSIX
systems don't HAVE case-insensitive file systems).

Nevertheless, the flag is generic and not tied to Windows, etc. so this
should be fixed.

That code (hash.{c,h}) was actually taken from the GNU id-utils source so we
should check and see if there have been enhancements.

___

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.

[Paul D. Smith]

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

In fact, your original idea of passing -W  for each included file "foo"
so that the re-invoked make would realize it should not be built again WAS
implemented (by me) in an earlier version of GNU make.

However, it lasted only a few days out in the wild, because it immediately
hit build environments where many hundreds or even thousands of files were
included... and the re-exec of make failed because the environment was not
sufficiently large to be able to pass all those options through exec!

Considering there is really no way to ensure that you have enough space for
all possible uses, I took that code back out and reverted to the original
(and still current) behavior.

However, recently a new suggestion has been made which would enhance make to
understand "@-files", which are apparently becoming more common even on some
UNIX platforms as a way to pass large numbers of arguments.  If that feature
was added to GNU make then make could take advantage of it to propagate the
-W flags in a way that wouldn't blow out the environment.  See patch #5809

___

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 #19035] Make recompiles source files eventhough the files are not modified

[Paul D. Smith]

Update of bug #19035 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 


___

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 #18755] exported var-define and var-define from command line should appear in $(shell ) env

[Paul D. Smith]

Update of bug #18755 (project make):

  Status:None => Duplicate  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Yes, they did; I'm closing this as a duplicate of bug #10593

There is info there about why it works the way it does, and in fact in the
regression test suite there is a test (commented out) that shows that the
simple implementation of this feature (also commented out, as the above bug
shows) leads to an infinite recursion.

That's not to say that a more complicated implementation couldn't resolve
this problem, which is why the original bug is still open.

___

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 #19656] strcmpi does not exist on my system, better use strcasecmp instead

[Paul D. Smith]

Update of bug #19656 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => CVS

___

Follow-up Comment #4:

Fixed this by converting all uses of case-insensitive string comparisons to
use POSIX strcasecmp(), and either aliasing strcasecmp to OS-specific
versions like strcmpi/stricmp, or else using our own version (for things like
VMS).

___

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 #16389] Defaults for Objective-C

[Paul D. Smith]

Update of bug #16389 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => CVS

___

Follow-up Comment #8:

I added most of these rules.  One thing I didn't add was the default variable
setting "OBJCFLAGS = $(CFLAGS)".  That doesn't seem right to me; we don't do
that with C++ for example.  However, I don't program in objective C so maybe
I'm just missing something.  Let me know.

___

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 #18617] Better debugging facilities: tracing rule invocation.

[Paul D. Smith]

Update of bug #18617 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
Operating System:None => Any
   Fixed Release:None => CVS

___

Follow-up Comment #3:

I added a new debug statement to the "basic" debug output that specifies
where the command script was found for a given target, when make starts to
build that target.  For commands found in a makefile you get:

Invoking commands from : to update target `'.

For builtin commands, you get:

Invoking builtin commands to update 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 #19900] Target-specific variables not honored for rules generated by $(eval)

[Paul D. Smith]

Update of bug #19900 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

Closed.

___

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

[Paul D. Smith]

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

Note that GNU make has received a Google Summer of Code project, to implement
the ability for users to customize the "out of date" algorithm used by make. 
You might consider waiting a couple of months and see what comes of that by
the end of the summer.  I have high hopes that it will be flexible and
powerful enough to provide all the functionality people need to implement
various algorithms including things like comparing stored stat(2) info as
well as .KEEP_STATE capabilities.

___

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

[Paul D. Smith]

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

I can reproduce this as well and the fix seems simple enough.  The thing
that's concerning me is WHY does it only happen with parallel makes?  There
must be something non-obvious happening here because it doesn't seem to me
like parallelism should change this behavior in the least.

I need to look at that before I'll feel comfortable just fixing 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 #20033] parallel (-j2) make with $(eval) construct segfaults

[Paul D. Smith]

Update of bug #20033 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => CVS

___

Follow-up Comment #4:

OK, I found it.  I'm still not 100% sure why it makes a difference between
parallel and non-parallel jobs but I think I understand it.  The attached
patch definitely seems to fix the problem.

(file #13043)
___

Additional Item Attachment:

File name: 20033.diff Size:1 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 #20067] Unescaped meta characters in makefile database outputs

[Paul D. Smith]

Update of bug #20067 (project make):

  Item Group: Bug => Enhancement


___

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 #20018] Several inaccuracies/miswordings/typos in (texinfo) manual

[Paul D. Smith]

Update of bug #20018 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => CVS

___

Follow-up Comment #1:

> 3.5 The Variable `MAKEFILE_LIST'
Already fixed (bug #16304)

> 3.9 How `make' Reads a Makefile
Good catch; fixed this one.

> 4.2 Rule Syntax
Fixed a while ago.

> 4.9 Special Built-in Target Names
Fixed a few weeks ago.


Thanks for the report!

___

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

[Paul D. Smith]

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

I looked at this briefly and it's tough.  In order to get the proper behavior
for the target-specific variables, make has to modify the way the variable is
stored; once that happens it's pretty hard to reconstruct the way the
variable originally appeared in the makefile.

I'll look at it more closely; there might be a way to get back the original
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 #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1

[Paul D. Smith]

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

I hear your frustration but I cannot apply patches to the source code that I
do not fully grok, even if it is a one-line patch.  By this I don't mean just
"what does the one line do", which is easy, but rather why is that line
necessary, why is it only necessary when running -jN but not serially, what
is special about intermediate files in this context, etc.  It's always
possible that the fix you've provided ISN'T the best way to resolve the bug.

You were explaining the issue back in November after I asked for this;
however, at the end of your last comment you wrote "More later..." so I filed
this bug waiting for "more", and then it got lost in the shuffle.  Certainly
before any release candidates are created (if not before) I go through all
the open bugs; this one would have been re-examined then if not sooner.  If
you've said everything you have to say about this I'll look at it again this
weekend.

___

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

[Paul D. Smith]

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

It's not exactly correct to say that GNU make caches directories from the
10th on, but you're on exactly the right track; thanks for the note.

What make actually does is cache EVERY directory... BUT it caches them
"lazily", AND it only allows 10 directories to be open at any one time. 
Basically, when make wants to check a file in a directory it opens the
directory for reading and looks for that file.  As it reads the directory it
caches the contents.  Once the file is found, it leaves the directory open
but stops reading.  If make looks for another file in that directory and it's
not in the cache, make continues reading (and caching) where it left off.  If
it gets to the end of the directory it closes the directory.

In order to avoid too many directories being open by make at one time, if
make gets to a point where more than 10 directories are open, it will
completely read and cache the current (latest) directory, then close it.

The issue of make's caching is well-known (see bug #443 for example).  In
your case it takes an odd twist but this is definitely the issue.  A
completely correctly-written makefile shouldn't run across cache problems,
but I recognize there are situations where it's not possible to write that
makefile.  However, in your case I think you can do what you want.  Change
your makefile like this:


LIBS := $(patsubst %,-l%,$(SUBDIRS))
LIBTARGETS := $(foreach L,$(LIBS),$(L)/lib$(L).a)

all: $(TARGET)

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

$(LIBTARGETS): FORCE
$(MAKE) -w -C $(@D) -f Makefile $(MAKECMDGOALS)
FORCE:


This has some other advantages over the method you were using (for one thing,
your example does not work properly if any of the sub-makes fail).

___

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

[Paul D. Smith]

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

Something like that could be tricky to accomplish, since make is highly
recursive: when make starts checking for timestamps on files it doesn't know
whether that file was found using implicit or explicit rules, etc.

Plus, I think it would be even more confusing to have some kinds of targets
(implicit) behave unexpectedly while others (explicit) behaved as expected,
but more slowly.

To fix this problem we need to add a way to determine if the cache is stale.

My idea on how to do this is for make to keep a counter that is incremented
every time make invokes a subprocess.  Or maybe, from a correctness point of
view, it should be updated every time a subprocess _finishes_.  Then when a
directory was cached it would store the current value of that counter.  The
next time the cached data was consulted, if the current counter was greater
than the stored counter the cache would be considered stale and new data
would be read.

This would significantly reduce the efficiency of the cache, but it would
increase correctness and the cache would still be useful while make is
looking for things to build--for situations where there's very little or
nothing to do the cache would still be a big win.

___

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

[Paul D. Smith]

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

I said all bugs would be reexamined before a release: I didn't say they would
all be fixed before a release.  Bug 3330 _was_ looked at (by me) before 3.81
was released, but I thought it was bound up with the other issues surrounding
.SECONDARY and I elected not to spend time trying to fix it then.  It appears
that I didn't look at it closely enough; if I'd been more diligent I would
have seen that it was something else.  That was an error in judgment on my
part.

I'm sorry but I don't consider this bug critical enough to make a new release
for it alone.  This issue has been in the code since at least GNU make 3.75
(that's the farthest back that I tested it) which is over 10 years old, and
in all that time as far as I can tell from searching the mailing lists, etc.
only yourself and J. David Bryan have run into it.  That's not to say it's
not a bad bug: it is, and it will be fixed in 3.82.  But as for an immediate
bug fix release, I don't think it's justified in this case.  There are plenty
of instances where programs have bugs that crash or return incorrect results
on valid input, and an immediate release is not created for each of those. 
The question is, how many people will the problem affect and what is the
impact of the bug (security flaw, erases a disk, etc.)?  This bug simply
doesn't rise to the level needed to justify an emergency release to fix it,
in my opinion.

___

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

[Paul D. Smith]

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

OK, I went through both this bug and bug 3330 last night, and I do see the
problem; thanks for all your work and the patch you provided Icarus.

However, I'm not entirely sure that the way you solved this problem is the
best one.  Setting the state of the intermediate file to cs_not_started seems
incorrect to me; it does seem to solve the problem, at least for the cases
described in these bug reports, but it means that after we're done the
intermediate file is marked as "not started" which I'm not sure is correct.

Also, I do see J. David's issue with a pattern rule invoked twice on my
vanilla CVS head tree with the original patch applied.

I have an alternative change that feels more correct: after all the prereqs
of the intermediate file are done, if we don't need to make the intermediate
file then we call notice_finished_file() on it to complete it.  With this
patch, J. David's example works correctly as do the other examples in both
this bug and bug 3330.

I attach the code change only here: obviously the real fix will involve
change logs, test cases, etc.  I think your idea of having a timeout is a
good one, Icarus, but I think I will make it general so that EVERY test we
run has a timeout; these can be modified on a per test basis of course.

Please let me know whether this patch solves all the issues you have in real
life and any other comments you have.

(file #13283)
___

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 #20394] vpath directive drops entries

[Paul D. Smith]

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

I haven't looked into it carefully, but it's not immediately clear to me that
it's a simple thing to avoid the directory cache for chained/intermediate
rules, vs. any other kind of rule.

The disadvantage with the "is_stale" boolean is that every time something
goes stale you have to walk through the entire cache and reset all the
boolean values.

If you use a counter then you don't have to touch anything in the cache until
and unless you need to look at that cached data, then you compare (and update)
the counter kept with that set of data.

It may be that our caches are not large enough to make a difference,
practically speaking; I'm not sure.

___

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 #20452] Incorrect use of variable_buffer_output() in expand_deps() [file.c]

[Paul D. Smith]

Update of bug #20452 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => CVS

___

Follow-up Comment #1:

You're absolutely right.  Good catch.  One note: your fix for the second case
is incorrect; it should be:

d->name = strcache_add_len (variable_buffer, o - variable_buffer);


Patch attached.

(file #13338)
___

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

RE: problem

[Paul D. Smith]

Gupta, Sonia (Product Engineering Services, Mumbai) writes:

 > While doing qmake calculator.pro we get an error Qfile:: file not
 > specified.atleast 100 times. Can you tell us why is that.

No.  This list is for discussion of bugs and issues with building and
using GNU make itself.

First, unless you made a typo, you are using qmake, which is not GNU
make.

Second, even if you're really using GNU make your problem is with the
code you're trying to build (missing headers, librarires, etc.) and
not with GNU make itself.  You'll have to ask on a mailing list
dedicated to the software you're trying to build.

-- 
-----------
 Paul D. Smith <[EMAIL PROTECTED]>  Find some GNU make tips at:
 http://www.gnu.org  http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist


___
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

[Paul D. Smith]

Update of bug #15919 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => CVS

___

Follow-up Comment #22:

OK, I did a bunch more testing and created test cases to cover all the
aspects of this bug reported here and in 3330.  Fix committed.  Thanks to both
of you for your work on this 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 #3330] gmake -j2 does very different things to gmake -j1

[Paul D. Smith]

Update of bug #3330 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => CVS

___

Follow-up Comment #4:

OK, committed a fix for this (and bug #15919), plus test cases.  Thanks to
Icarus for all his work on this.

___

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

[Paul D. Smith]

Update of bug #20995 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 
 Summary: \ along multiple lines lines for '...' doesn't work
 =>  along multiple lines lines for '...' doesn't work 

___

Follow-up Comment #1:

Hi Frank; the 3.81 behavior is correct.  The POSIX spec for make says:

When an escaped  is found in a command line in a makefile, the
command line shall contain the backslash, the , and the next line,
except that the first character of the next line shall not be included if it
is a .

See the GNU make manual subsection "Splitting Command Lines" (node "Splitting
Lines"), in section "Command Syntax", chapter "Writing the Commands in Rules",
for details.

We are discussing adding a ".ONESHELL" feature for the next version of GNU
make; if we do that then this could be used to get the kind of behavior you're
looking for.

___

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

[Paul D. Smith]

Update of bug #20549 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => CVS

___

Follow-up Comment #4:

Applied Eli's fix for this.

___

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 #21376] Random Segmentation fault when run with -j n

[Paul D. Smith]

Update of bug #21376 (project make):

  Status:None => Duplicate  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

This is a duplicate of bug #20033.  There's a patch attached to that bug.

I only was able to determine this by looking at the stack trace you provided
to the mailing list; when reporting bugs please remember to add in stack
traces, etc. wherever possible.

Cheers.

___

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 #21661] Make expands command-line variable defnitions after/during every command invocation

[Paul D. Smith]

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

Ah, now it's clear what the confusion is.  This happens because make puts
command line variable settings into the environment to be exported to the
subshell.  And, of course, before make can invoke a subshell it has to expand
all the variables that are to be exported.

See
http://www.gnu.org/software/make/manual/html_node/Variables_002fRecursion.html#Variables_002fRecursion

You can avoid this by adding an explicit "unexport var" to your 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 #21661] Make expands command-line variable defnitions after/during every command invocation

[Paul D. Smith]

Update of bug #21661 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

Dave is correct: this is exactly how make should behave; it's not a
regression (because all versions of make have always behaved this way); it's
not even a bug.  Setting a variable on the command line using "var=value" is
conceptually exactly the same as having that same assignment appear at the end
of the last makefile make reads in (because the value on the command line
takes precedence over values set in the makefile).

If you put "var=value" in your makefile, then the left hand side of the
variable will be re-expanded every time the variable "var" is referenced.

As Dave suggests, you should review the difference between simple variables
and recursive variables, and/or the difference between immediate and deferred
expansion.  You can read about these topics in the "How make Reads a Makefile"
section of the manual, here:
http://www.gnu.org/software/make/manual/html_node/Reading-Makefiles.html#Reading-Makefiles

___

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

[Paul D. Smith]

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

Can you please explain clearly what exactly happens, AND what you expected to
happen?  I have no idea, based on the descriptions you provided, what the
actual problem is.

___

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

[Paul D. Smith]

Update of bug #22198 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 


___

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 #22379] Segmentation fault with wildcard archive rule

[Paul D. Smith]

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

No, that Debian bug is different (and that whole section of code is different
in the next release of GNU make, so it's no longer needed).

Please try the attached patch and see if it works.

(file #15253)
___

Additional Item Attachment:

File name: p.diff Size: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 #22379] Segmentation fault with wildcard archive rule

[Paul D. Smith]

Update of bug #22379 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => CVS

___

Follow-up Comment #3:

I'm closing this as the bug is fixed in my testing.

___

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

[Paul D. Smith]

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

I'm not sure your reading of POSIX is correct.  It says:

-
Inference rules can be redefined. A target that matches an existing inference
rule shall overwrite the old inference rule. An empty rule can be created with
a command consisting of simply a semicolon (that is, the rule still exists and
is found during inference rule search, but since it is empty, execution has no
effect). The empty rule can also be formatted as follows:

rule: ;

where zero or more s separate the colon and semicolon.
-

To me this seems to reaffirm make's behavior: the rule exists and is found
during inference rule search, but execution has no effect.

I think you can get the behavior you want by some combination of removing
suffixes in .SUFFIXES, and perhaps changing the order in which they appear.

If not can you provide a simple test case?  You can dummy out the actual
compilation with touch and cp etc. 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 #21823] Potential NULL pointer dereference on hash.c, hash_insert

[Paul D. Smith]

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

This is confusing, and the lack of detailed comments in hash.c doesn't help.

However, I think this particular bug is impossible.  Looking at the
implementation of hash_find_slot(), it seems there is no way for that function
to return null.  So, the test in hash_insert() to see if slot is null is
unneeded and we can never pass null to hash_insert_at() from hash_insert().

That useless check in hash_insert() should be removed to avoid a bit of
confusion and a useless operation or two.

___

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

[Paul D. Smith]

Update of bug #21716 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 


___

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)

[Paul D. Smith]

Update of bug #23468 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

As Anonymous points out, this is a change that was required for POSIX
conformance.

Note you can overcome this by putting your long perl script in a make
variable; instead of:

foo:
perl -e 'my multi-
line perl script'

you can use something like:

PERL_SCRIPT = my multi-
 line perl script
foo:
perl -e '$(PERL_SCRIPT)'

The latter will work the same in all versions of make, and is arguably easier
to read and understand as well.

___

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 #23793] MAKEFLAGS with only variable settings X=y does not work properly

[Paul D. Smith]

Update of bug #23793 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

I don't believe this is a bug.  The GNU make manual says:

`MAKEFLAGS' begins with a hyphen only when it begins with an option that has
no single-letter version, such as `--warn-undefined-variables'

In general, it's not correct to put $(MAKEFLAGS) in a recipe line when
invoking a sub-make.  MAKEFLAGS is intended to be passed to the sub-make
through the environment, not the command line, and this will happen
automatically for you all the time.

Sub-makes should be invoked as just $(MAKE), with no $(MAKEFLAGS).

For more information, see section "Communicating Options to a Sub-make" in
the GNU make 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

[Paul D. Smith]

Update of bug #24164 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

The followup comments are correct and this is expected and documented
behavior; I'm closing this as "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 #22923] option to prevent "interspersed" output in parallel builds

[Paul D. Smith]

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

It's not actually quite that simple, although it's do-able.  Make is not a
multi-threaded application, and so it cannot read from multiple streams at the
same time (such as stdin and stderr, either for a single job or for multiple
jobs) without a lot of complexity and potential loss of performance.

The only realistic way this could be done would be, as bkustel mentions,
redirecting the output of each job to a temporary file then printing the
contents of that file after the job is complete.  It would be necessary to
redirect both stdout and stderr for each job to one file and there's no way to
"mark" them, since make is not actually processing the output of the jobs.

Similarly, ijprest's idea of having make read lines and print them, prefixed
with a job number, cannot really be implemented by make itself for the reasons
mentioned in the first paragraph.

However, one idea would be a new special variable that defined a program that
job output would be piped to.  If that variable was set, then every time make
runs a job it would run this program and arrange for all stdout/stderr from
the job to be piped to the command line that was the value of that variable. 
It could have various format options that could optionally be provided, to
give a job number, the command being invoked, or whatever.  Then people could
provide their own script or program that did whatever they liked: stored the
output and printed it all at the end, or printed it line-by-line with a job
prefix, etc.

___

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 #24486] Have make print a progress report during build?

[Paul D. Smith]

Update of bug #24486 (project make):

Severity:  3 - Normal => 1 - Wish   

___

Follow-up Comment #1:

There is no good way to do this without completely rearchitecting how GNU
make works.

See:

http://www.mail-archive.com/[EMAIL PROTECTED]/msg06212.html

for example.

___

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 #24522] $(info) does not nothing

[Paul D. Smith]

Update of bug #24522 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

The $(info) function was added in GNU make 3.81.

___

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 #24723] multiple results created as a group

[Paul D. Smith]

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

Make can already do this with pattern rules.  I'm assuming you mean with
explicit rules?

___

Reply to this item at:

  

___
  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 #25140] Pattern-specific variable assignment behaves differently compared to normal variables

[Paul D. Smith]

Update of bug #25140 (project make):

  Item Group: Bug => Enhancement

___

Follow-up Comment #1:

The reason this happens is because pattern-specific variables are treated
very differently from target-specific variables, internally.  With
target-specific variables there is an actual target and the variables are kept
and expanded with reference to that target.  Since an explicit target is
stated, even if that target is not known already we can create one to hook
these variables to when the makefile is read in.

With pattern-specific variables there is no known target at the time the
pattern variable is defined, so pattern variables are simply kept as a list of
potential variable settings.  They are not resolved when the makefile is read
in, because there's no target to "hook" them to.  They are resolved when the
target is to be built: at that time all the pattern-specific variable patterns
are matched, one at a time, to the target and if it matches the expansion
occurs.  Obviously that comes in the second phase of the build, after the
makefiles have all been read in (and, in your example, the variable $(v) has
been reset).

It's potentially conceivable that all the pattern-specific variables with the
exact same pattern could be treated as target-specific variables are, and the
variable settings for that pattern can be combined into a "group".  However,
even that would not be 100% accurate; suppose you had two patterns "%.bar" and
"foo%.bar", then with a target of "foobaz.bar" you could reasonably expect the
pattern-specific variables to be handled as if they were target-specific
variables for "foobaz.bar"... but there's really no way to do that.

This behavior is actually quite tricky to get right: combining :=, +=,
inheritance, etc.

I'll leave this open as an enhancement request.

___

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 #25190] define expansion seems to lose the final newline

[Paul D. Smith]

Update of bug #25190 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

This is not a bug.  See the GNU make manual, section "Defining Variables
Verbatim", where it says:

The value in an ordinary assignment cannot contain a newline; but the
newlines that separate the lines of the value in a `define' become part of the
variable's value (_except for the final newline which precedes the `endef' and
is not considered part of the value_).

Note the final parenthetical comment (highlight added).

___

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 #25578] target without target specific variable setting receives setting from unrelated target

[Paul D. Smith]

Update of bug #25578 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

The problem is you forgot a backslash in the programs/retriever/rules.mk
file, so the variable assignment is not attached to the target but is rather
just a normal assignment.


lib/libOPSCarchretrhook.$(SL):
LINK_LIBS:=
   OPSCcomm 
   OPSCbase 
   errors


Should be:

lib/libOPSCarchretrhook.$(SL): 
LINK_LIBS:=
   OPSCcomm 
   OPSCbase 
   errors


You can find out where variables were assigned very easily by running make
with the "-p" option; this will print the entire database make used, and the
filename/linenumber where each was defined in the 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 #25578] target without target specific variable setting receives setting from unrelated target

[Paul D. Smith]

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

Hm.  The markup seems to have swallowed my "should be" section.  Also, the
email seems to have deleted ALL the backslashes.  Anyway, you get the idea.

___

Reply to this item at:

  

___
  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 #20495] debug version crashes on windows on close(-1)

[Paul D. Smith]

Update of bug #20495 (project make):

  Status:None => Fixed  
 Assigned to:None => eliz   
 Open/Closed:Open => Closed 
   Fixed Release:None => 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 #25844] Spelling error in French debugging messages

[Paul D. Smith]

Update of bug #25844 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Hi; note that translation is not handled by the GNU make team, but rather by
the GNU translation team.  There's not much we can do to fix this problem,
because we dynamically download the latest translation from the GNU
translation team every time we build a new release; the translations are not
kept in the GNU make source tree so we can't keep updates.

You need to contact the translation team for the language you're concerned
about.  You can start here: http://translationproject.org/domain/make.html to
find the right team.

I'm closing this bug in Savannah, but feel free to reopen if you have
troubles.

___

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 #26075] $(wildcard) function holds parent directories open preventing deletes

[Paul D. Smith]

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

Hm, that's interesting.  There's no doubt that the directory cache causes
unexpected consequences when your makefile does things "behind the scenes"
that make doesn't know about (so it can't update the cache appropriately).

However, this is the first time I've ever heard the assertion that it is
actually slower than no cache at any time, much less on average, or by
magnitudes.

I'm not saying you're wrong, because I've never tested it myself.  But, do
you have any hard data to prove this assertion?

___

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 #26307] gnash in firefox high CPU

[Paul D. Smith]

Update of bug #26307 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

I'm not sure why you're posting this bug in the GNU make bug tracker.

___

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 #26001] Evaluating eval expressions does not work for % type names

[Paul D. Smith]

Update of bug #26001 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

Olexiy is mostly correct: if you don't escape the call then it will be
expanded as the makefile is read in, as with all variables and functions that
appear in prerequisites.  At that time, the pattern "%" is not a special value
so basically you're calling the reversLookup function with the literal string
"file%", which obviously won't do what you want.

What you need to do, if you want to do this, is define the .SECONDEXPANSION:
pseudo-target then do something like:

file%: $$(call reverseLookup,$$@)

See the section on "Secondary Expansion" in the GNU make 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 #26207] corner cases in 'override' logic for variables

[Paul D. Smith]

Update of bug #26207 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => CVS

___

Follow-up Comment #1:

The initial behavior is indeed correct, as Manoj has explained.  Once a
variable is elevated to the status of "override", which is the highest
priority a variable can have, any subsequent assignment or append to that
variable which is of a lower priority will be ignored.  You can continue to
append to that variable, or even change its value, but only if you precede the
subsequent assignments with "override" as well.  I added some text to the GNU
make manual that might make this clearer.

As for the other effects you observed, those are due to a real bug in the
system.  I've attached a patch here which I will be committing as soon as
Savannah's source control systems come back up.

(file #18213)
___

Additional Item Attachment:

File name: read.diff  Size: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 #25460] make -n better documentation

[Paul D. Smith]

Update of bug #25460 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => CVS

___

Follow-up Comment #2:

Modified the GNU make manual and man pages to give appropriate caveats.

___

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 #25694] New functions missing in quick reference

[Paul D. Smith]

Update of bug #25694 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => CVS

___

Follow-up Comment #1:

Fixed in source code.  Thanks.

___

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 #25697] Segmentation fault setting .DEFAULT_GOAL

[Paul D. Smith]

Update of bug #25697 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => CVS

___

Follow-up Comment #2:

The issue here is by doing this:

.DEFAULT_GOAL := $(myDefaultGoal)  #restore the previous default rule

you are actually setting the .DEFAULT_GOAL variable to contain a single space
rather than an empty string--make always preserves all TRAILING whitespace
after a value, so any space between the value and a comment, for example, is
included in the value.

Obviously make should not crash even so, and I've fixed this bug; now you'll
get:

make: *** No targets.  Stop.

I also noticed make wasn't expanding this variable before use, which is
wrong.  Fixed that too.

___

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 #26307] gnash in firefox high CPU

[Paul D. Smith]

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

Well, I surely don't know.

GNU make is a tool used to control compiling programs.  It has absolutely
nothing to do with Firefox, Gnash, Red Hat, swfdec or any other codec, or
anything else related even remotely to the problem you're having as far as I
can determine.

I recommend using Google to search for something like "gnash bug reporting"
or similar.

___

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 #24622] $$(eval) creating new targets causes segmentation fault

[Paul D. Smith]

Update of bug #24622 (project make):

  Status:None => Duplicate  
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

This is a duplicate of bug #24588

___

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 #24588] $$(eval) with SECONDEXPANSION causes segmentation faults

[Paul D. Smith]

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

See also duplicate bug #24622 for another example.

___

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 #24488] phony targets are case insensitive with case insensitive file system

[Paul D. Smith]

Update of bug #24488 (project make):

  Item Group: Bug => Enhancement

___

Follow-up Comment #1:

I'm not convinced that this request is something we actually want to
implement; .PHONY is not only used for completely phony targets (where using
case-sensitive matching would make sense), it's also used to mark real files
that could appear on the filesystem as "always rebuilt" for various reasons. 
In this case you would want them to be treated case-insensitively.

Even if we wanted to do this, there's no easy way to do it: the
--enable-case-insensitive flag is a _compile-time_ flag which changes the
entire behavior of make at a code level.  There is no facility in the codebase
today to track case-insensitive flags on a per file target.

As for special targets not being case-insensitive, that is not a bug. 
Case-insensitivity does not apply to special documented targets like .PHONY
etc.

I'm marking this as "Enhancement" right now but I'm inclined to close it as
"Not a Bug".  Comments requested.

___

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

[Paul D. Smith]

Update of bug #23986 (project make):

  Status:None => Works for me   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

You need to get the version of Linux installed in the Ronco Auto-Kitchen
9000, then drop to the command line and run "make cookies" from there.

___

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 #24277] make leaks FDs through $(shell)

[Paul D. Smith]

Update of bug #24277 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => CVS

___

Follow-up Comment #2:

Thanks for the report.  I ended up fixing this slightly differently, by
adding a test for fileno() into configure.in and running CLOSE_ON_EXEC() on
fileno() of the FILE*.  Checking /proc/self/fd in a $(shell ...) confirms this
works.

___

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

[Paul D. Smith]

Update of bug #24251 (project make):

 Privacy: Private => Public 
 Open/Closed:Open => Closed 


___

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 #24488] phony targets are case insensitive with case insensitive file system

[Paul D. Smith]

Update of bug #24488 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 


___

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 #16670] Repeated backslash-escaped newlines not POSIXly replaced

[Paul D. Smith]

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

OK, the fix for this is simple enough.  However, it does cause user-visible
changes.  It's not so much the replacing of each backslash/newline/following
whitespace with a space that's the issue, it's the fact that TRAILING
whitespace on the previous line is no longer condensed.  The current behavior
basically condenses ALL whitespace starting with the last non-whitespace
character on the previous line and going until the next non-whitespace
character (where backslash/newline are considered whitespace) and replaces it
with a single space.  So, in the current version of make this:

FOO = a
 b

Gives a value of $(FOO) that is "a b".  In the new behavior this would give
"a b", because the trailing whitespace on the previous line is
preserved, plus one extra space for the backslash/newline/following
whitespace.

___

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 #16670] Repeated backslash-escaped newlines not POSIXly replaced

[Paul D. Smith]

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

Ugh.  Savannah's comments kind of suck.  I mean, the current behavior gives:

a b


and the POSIXly-correct behavior would give:

a b


___

Reply to this item at:

  

___
  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 #26593] Assertion failure when building glibc with CVS make

[Paul D. Smith]

Update of bug #26593 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => CVS

___

Follow-up Comment #3:

Yes, this is bad.  The fix is simple as you suggest.

___

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 #24588] $$(eval) with SECONDEXPANSION causes segmentation faults

[Paul D. Smith]

Update of bug #24588 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => CVS

___

Follow-up Comment #3:

Fixed using a change almost identical to yours.  Thanks!

___

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 #24655] shell_var.length isn't set causing duplicates from target_environment.

[Paul D. Smith]

Update of bug #24655 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => CVS

___

Follow-up Comment #1:

I can't reproduce the problem (I don't get failures in the SHELL unit tests)
but I agree that the change you proposed is necessary and I've made it in the
source code.

___

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 #25712] "make update" does not work in an out-of-source-tree configuration

[Paul D. Smith]

Update of bug #25712 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => CVS

___

Follow-up Comment #1:

This is not officially supported but I made changes to allow it to work.

___

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

[Paul D. Smith]

Update of bug #15919 (project make):

  Status:   Fixed => None   
 Open/Closed:  Closed => Open   

___

Follow-up Comment #28:

I've been running the unit tests for months and never had a failure in
targets/SECONDARY.  I still don't, using the latest downloaded code (there is
an odd issue with variable/SHELL that I don't see at home but do see here as a
result of my checkins over the last week; I think the test is wrong bug I
don't understand why I didn't see this at home).

I tried to reproduce the INTERMEDIATE file failure by editing the
INTERMEDIATE test file and adding "-j2" and "-j5" to the
"run_make_with_options" invocations for test 3, 4, and 5 and I got correct
behavior there as well; no errors reported.

I wonder if this is somehow behaving differently on Linux?

___

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

[Paul D. Smith]

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

I took a copy of glibc 2.9 and tried building it with -j10 on my uniprocessor
and on my dual core (actually single hyperthreading CPU) and it worked fine.

But when I took it to a 4-way hyperthreading (8 core) system and ran with
-j10 I did see some bad behavior: not hangs though.  Instead it seemed the
same recipe was being invoked >1 time which eventually caused the build system
to fail, because at the end of the recipe there's a job that removes a file. 
If the multiple recipes run in the "right" way then one of the instances
removes that file before the next one gets a chance to use it.

I'll look at this.

___

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

[Paul D. Smith]

Update of bug #15919 (project make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 

___

Follow-up Comment #30:

I debugged this and applied the change Knut suggested; after this glibc with
make -j10 builds without error.

___

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 #25703] .LIBPATTERNS is not pattern dependent.

[Paul D. Smith]

Update of bug #25703 (project make):

  Item Group: Bug => Enhancement

___

Follow-up Comment #1:

I'm marking this as an enhancement, since the code works as designed.  I
agree it would be nice to allows LIBPATTERNS (and VPATH!) to use
target-specific and pattern-specific values.

Right now, though, we don't set up the variable sets properly before doing
the lookups for this to happen.

___

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.

[Paul D. Smith]

Update of bug #22010 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => CVS

___

Follow-up Comment #1:

Fixed; if I change the stack limit I remember the original value and reset it
after forking for a job.  I also added ulimit to the list of shell commands so
make will choose the slow path when ulimit is present.

___

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

[Paul D. Smith]

Update of bug #22434 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #6:

This problem is happening because in your Viewer.cpp file you say:

#include "Viewer"

Because of this, when automake generates the automated prerequisites for the
.o file (in src/.deps/) one of the prerequisites is the simple word "Viewer".

When make sees that prerequisite, it tries to build it.  Make has no idea
that you really mean a header file here that it can't see: it looks for a file
"Viewer" and one doesn't exist, so it tries to build it.  Make has a built-in
rule that says "you can build any program FOO from FOO.cpp", and since it
wants to build Viewer and it finds a Viewer.cpp... voila.  It tries to compile
it and fails.

This may or may not be a bug, but if it is it's a problem in automake's
automated dependency generation, not 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 #22442] Old-style cancelation of implicit rules

[Paul D. Smith]

Update of bug #22442 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

Closing.  Feel free to re-open if you have more details.  But, if you're just
looking for help then the help-m...@gnu.org mailing list might be more
productive.

___

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 #23361] Infinite loop when including file that depends on a phony target

[Paul D. Smith]

Update of bug #23361 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

Dave's comment is correct.  This is behaving as expected.  Not ideally, but
as expected.  Since make re-execs itself it's actually quite difficult to know
what files were already built by a previous incarnation.

For a while I had a feature where the re-exec would add -o options for all
makefiles rebuilt so that the next invocation would not try to rebuild them. 
However, some people rely on this behavior AND it also caused problems with
makefiles that have lots of included files: the re-exec was failing due to
running out of environment space.

___

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

[Paul D. Smith]

Update of bug #23210 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

The problem is that the mtime of objects in an archive is based on the format
of the archive.  There's not much we can do about this: it is what it is.  If
the timestamp of the objects in the archive is 1 second granularity, then
that's all we have.

___

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(?)

[Paul D. Smith]

Update of bug #21854 (project make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
   Fixed Release:None => CVS

___

Follow-up Comment #2:

This bug has already been fixed in the latest CVS version of 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 #21823] Potential NULL pointer dereference on hash.c, hash_insert

[Paul D. Smith]

Update of bug #21823 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => CVS

___

Follow-up Comment #4:

Fixed by removing the confusing test.

___

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