[bug #58364] Inconsistent behavior between 4.3 and 4.2.1

Follow-up Comment #8, bug #58364 (project make): I agree that it is unfortunate and these things can happen. The "breaking change" was due to the extra number of output lines (and for CMake) with a different syntax and might break automatic scripts. I also think that CMake is widely used but the

[bug #58364] Inconsistent behavior between 4.3 and 4.2.1

Follow-up Comment #6, bug #58364 (project make): It is indeed hard to communicate the breaking change to the users / community when it is not in the initial NEWS file. I don't think there isn't a lot that can be done. The current way it is in the, to be released, NEWS file is in my opinion not an

[bug #58364] Inconsistent behavior between 4.3 and 4.2.1

Follow-up Comment #2, bug #58364 (project make): The background of the problem is actually that in cmake now, by default, also the Entering / Leaving messages appear. In the past they were automatically suppressed. People using CMake can also set the MAKEFLAGS environment variable, but it would b

[bug #58364] Inconsistent behavior between 4.3 and 4.2.1

URL: Summary: Inconsistent behavior between 4.3 and 4.2.1 Project: make Submitted by: albert_2 Submitted on: Wed 13 May 2020 02:12:34 PM UTC Severity: 3 - Normal Item Gr

I found a bug with Makefile

Hello ! I have really no idea about who i am talking !  I am a french student programmer, and making a school project with termcaps named ft_select (you can find many of this project on github) It's a termcaps introdution by creating a small selecting item menu. I always lunch my program with a

\ bug in CVS

I've built from CVS and have the following problem: $ cat Makefile rule: echo 'foo\ ' >/tmp/b $ gmake echo 'foo\ ' >/tmp/b $ cat /tmp/b foo\ Shouldn't /tmp/b contain "foo"? -- albert chin ([EMAIL PROTECTED]) _

Re: functions/realpath test failure on AIX

On Wed, Jul 06, 2005 at 11:46:30AM +, Boris Kolpackov wrote: > Albert Chin <[EMAIL PROTECTED]> writes: > > > On AIX 4.3.3, 5.1, and 5.2, $(realpath .///) appends "/": > > $ cat /tmp/a > > .PHONY: all > > all: > > @echo $(CURDIR)

functions/realpath test failure on AIX

/a /opt/build/make-3.81beta3/tests /opt/build/make-3.81beta3/tests/ -- albert chin ([EMAIL PROTECTED]) ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make

sys_siglist error on IRIX, Tru64 UNIX, HP-UX

IRIX has _sys_siglist. Tru64 UNIX has __sys_siglist. -- albert chin ([EMAIL PROTECTED]) -- snip snip --- configure.in.orig 2005-07-05 14:32:45.287084000 -0500 +++ configure.in2005-07-05 14:33:39.677488000 -0500 @@ -167,8 +167,9 @@ fi fi -AC_CHECK_DECLS([sys_siglist

Test failure on Solaris

$make_name = $make_path; } } $ cd /opt/build/make-3.81beta3 ./make -f /dev/null make: *** No targets. Stop. Because of the above, make_name is set to 'make'. -- albert chin ([EMAIL PROTECTED]) ___ Bug-ma

Re: better symlink handling

On Tue, 2004-07-20 at 11:42, Paul D. Smith wrote: > There are a number of suggestions already available in the bugs and > patches sections of GNU make's Savannah project. Something will appear > in the next version of GNU make. The proposed command line options will not do, because users won't re

better symlink handling

Something with syntax similar to .PHONY, for use of lstat() in place of stat(), might help a bit: .LSTAT: my-symlink-target another-symlink-target Also, have a way to declare this behavior for all targets. Some way to depend on the symlink content (readlink) might be much better though.

makefile include dependency bug/feature

;make" gets confused when a file is being used for both an implicit rule, include file, and target dependency. It should recognize the first implicit rule doesn't match, and reference the second implicit rule. However, if we change the BAR definition to hold the absolute path, we do g

Re: Make 3.80 on Tru64 UNIX 4.0D

n? > > http://savannah.gnu.org/bugs/?func=detailbug&bug_id=1517&group_id=71 Same error. -- albert chin ([EMAIL PROTECTED]) ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make

Make 3.80 on Tru64 UNIX 4.0D

:19 2002 *** *** 1,2 ! AA BA --- 1,2 ! A BA -- albert chin ([EMAIL PROTECTED]) ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make

$@ documentation

I have make 3.79.1. This stuff starts off with $(BINFILES) being a list of files to install, such as: /bin/foo /usr/bin/bar /sbin/baz this didn't work $(BINFILES) : $(notdir $@) $(install) --mode a=rx --strip $(notdir $@) $@ - It seems m

Re: Redhat Linux 7.1 and GNU make 3.79.1

RIX, and Solaris and > LD_LIBRARY_PATH is in the output. Ok, nevermind. make was sgid. -- albert chin ([EMAIL PROTECTED]) ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make

Redhat Linux 7.1 and GNU make 3.79.1

$ cd /tmp $ cat a.sh #!/bin/sh LD_LIBRARY_PATH=bar make all $ cat Makefile all: set $ /tmp/a.sh | grep LD_LIBRARY_PATH [empty] Why? I've tried the above on AIX, IRIX, and Solaris and LD_LIBRARY_PATH is in the output. -- albert chin ([EMAIL PROT

make 3.79 timestamp problem

Not sure if this is a solaris bug or a make bug, but it works fine in make-3.78.1. It appears make now treats targets with the same timestamp as the prerequisite as out of date. That didn't happen with make-3.78.1. Albert all: foo $(foobar) foo : bar @echo

make 3.79 status problem

Doing a "make -q" with the following makefile returns a 1 status where it should really return a 0 status. Can this be fixed? I know I could wrap an ifndef expression around the ALL commands, but I use this a lot. Thanks, Albert commands := .PHONY: all

Re: ifdef problem

Paul D. Smith writes: > From: "Paul D. Smith" <[EMAIL PROTECTED]> > To: "Albert L. Ting" <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: ifdef problem > Date: Tue, 13 Jun 2000 13:03:08 -0400 (EDT) > > %% "Albert L. Ting" &

ifdef problem

means the variable is undefined. Thanks, Albert

COFLAGS undefined

when using the --warn-undefined-variables switch, it complains about COFLAGS being undefined. Could you possibly set this variable to a blank? Thanks, Albert *** default.c 2000/03/23 18:08:17 1.1 --- default.c 2000/03/23 18:08:37 *** *** 285 --- 286

Re: conflict between RCS and VPATH

John Gerard Malecki writes: > From: John Gerard Malecki <[EMAIL PROTECTED]> > To: "Albert L. Ting" <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED] > CC: Lyndon Lim <[EMAIL PROTECTED]> > CC: "Scott L. Bordelon" <[EMAIL PROTECTED]> &

conflict between RCS and VPATH

> RCS > Any file `N' is extracted if necessary from an RCS file named > either `N,v' or `RCS/N,v'. `N' will not be extracted from RCS if it > already exists, even if the RCS file is newer. The above rule, where the RCS file is newer, does not seem to work if the loc

minor bug: COFLAGS should have a default value

When running make with the --warn-undefined-variables switch, it complains about COFLAGS not being defined. This variable ought to be set to something, even a blank. This is with make-3.78.1