[bug #27381] wildcard function acts differently than in 3.81

Follow-up Comment #1, bug #27381 (project make): sorry, it submitted by accident. wildcard in 3.81 always came back as a sorted list. in CVS, it was changed to use GLOB_NOSORT. This causes wildcard to not return a sorted list. This changes the behavior of wildcard. Is there a reason not to sor

[bug #27381] wildcard function acts differently than in 3.81

URL: Summary: wildcard function acts differently than in 3.81 Project: make Submitted by: mtrinh Submitted on: Fri 04 Sep 2009 05:09:17 PM GMT Severity: 3 - Normal Item

[bug #27381] wildcard function acts differently than in 3.81

Follow-up Comment #3, bug #27381 (project make): Thanks for the explanation. I would like to know if the NOSORT is needed to workaround a bug. Adding $(sort ...) is an acceptable workaround for my wildcards that needs sorting. ___ Reply

glibc build process slowness

same as the old rule's target See attached makefile which demonstrates this. Is that the correct behaviour? It seems like it would make more sense to compare the target lists for equality. Mark diff --git a/rule.c b/rule.c index e988db5..6e12439 100644 --- a/rule.c +++ b/rule.c @@ -2

[PATCH 3/5] Refactor: Use a doubly-linked list of rules instead of a singly-linked list

--- implicit.c |2 +- rule.c | 86 +--- rule.h |7 +++-- 3 files changed, 41 insertions(+), 54 deletions(-) diff --git a/implicit.c b/implicit.c index d239952..82f2c79 100644 --- a/implicit.c +++ b/implicit.c @@ -301,7 +301

[PATCH 1/5] Refactor: Move rule comparisons into separate functions

--- rule.c | 95 +--- 1 files changed, 55 insertions(+), 40 deletions(-) diff --git a/rule.c b/rule.c index ee96ec1..d08383b 100644 --- a/rule.c +++ b/rule.c @@ -273,6 +273,34 @@ convert_to_pattern (void) } +static int +rule_targe

[PATCH 0/5] Improve performance of rule handling

I have not changed the logic that decides whether one rule should override another. The patches are based on CVS HEAD. Cheers, Mark ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make

[PATCH 2/5] Clean up count_implicit_rule_limits()

* Removed unused variable, simplify loop. * Corrected comment. --- rule.c | 13 +++-- 1 files changed, 3 insertions(+), 10 deletions(-) diff --git a/rule.c b/rule.c index d08383b..a12f9d1 100644 --- a/rule.c +++ b/rule.c @@ -61,28 +61,24 @@ unsigned int maxsuffix;  /* Compute the

[PATCH 4/5] Record rule targets in a hash table

This is not used to replace any lookups yet. --- main.c |1 + rule.c | 75 rule.h |1 + 3 files changed, 77 insertions(+), 0 deletions(-) diff --git a/main.c b/main.c index ba7f87d..351e92c 100644 --- a/main.c +++ b/main

[PATCH 5/5] Hook up hash table: use for searching for rules to replace

--- rule.c | 52 1 files changed, 28 insertions(+), 24 deletions(-) diff --git a/rule.c b/rule.c index af1cefa..3ffc6bd 100644 --- a/rule.c +++ b/rule.c @@ -340,35 +340,39 @@ rule_dependency_lists_equal (struct rule *rule1, struct rule *rule

[bug #26593] Assertion failure when building glibc with CVS make

s.com) but I wasn't logged in to Savannah at the time. Mark ___ Reply to this item at: <http://savannah.gnu.org/bugs/?26593> ___ Message sent via/by Savannah ht

[bug #26593] Assertion failure when building glibc with CVS make

Follow-up Comment #2, bug #26593 (project make): Here's a smaller test case: $ cat test.make all: foo.suffix1 foo.suffix2 prefix1.foo prefix2.foo prefix1.% prefix2.%: %.original @echo $@ %.suffix1 %.suffix2: %.original @echo $@ .PHONY: foo.original # Expected output $ make -

Re: strcache scaling issue

On 09/01/2011 07:59, Ralf Wildenhues wrote: Index: strcache.c === RCS file: /cvsroot/make/make/strcache.c,v retrieving revision 2.9 diff -u -r2.9 strcache.c --- strcache.c 13 Jul 2010 01:20:43 - 2.9 +++ strcache.c 9 Jan 20

win32 compilation of make 4.0 source code‏

I was able to compile the make 4.0 source code downloaded from the gnu make site using Visual C++ 2005 under Windows 7 64 (generated 0 errors, 259 warnings) but executing the resulting make command file from the Windows 7 DOS Command Prompt yields a series of warnings/errors: ===

win32 compilation of make 4.0 source code

I was able to compile the make 4.0 source code downloaded from the gnu make site using Visual C++ 2005 under Windows 7 64 (generated 0 errors, 259 warnings) but executing the resulting make command file from the Windows 7 DOS Command Prompt yields a series of warnings/errors:

Re: win32 compilation of make 4.0 source code‏

As mentioned I used Visual C++ 2005, loading the project file and building it: make_msvc_net2003.vcproj . This results in a make_msvc.net2003.exe of length 892 KB being created in the debug directory. If this is not the intended compilation method, do give step by step method to compile the

Re: win32 compilation of make 4.0 source code‏

ateProcess(NULL, basename "", ...) failed. make: '.' is not recognized as an internal or external command, operable program or batch file. ... = -Original Message- From: Eli Zaretskii Sent: Monday, January 13, 2014 8:51 P

Re: win32 compilation of make 4.0 source code‏

IX systems, are you ? This makefile relies on UNIX shell commands like uname, pwd, basename, etc. Right ? In order to run this Makefile, you need Cygwin or MinGW32 environment. Well, there are native Windows ports of these commands as well (e.g., on the GnuWin32 site). But I'm not su

Re: win32 compilation of make 4.0 source code‏

evaluation within a Target evaluation. -Original Message- From: Paul Smith Sent: Friday, January 24, 2014 11:28 AM To: Mark Brown Cc: Eli Zaretskii ; Pavel Fedin ; bug-make@gnu.org Subject: Re: win32 compilation of make 4.0 source code‏ On Fri, 2014-01-24 at 11:03 -0800, Mark Brown wrote: I had

Re: win32 compilation of make 4.0 source code‏

ntation in Make version 4.1 . -Original Message- From: Paul Smith Sent: Monday, January 27, 2014 9:35 AM To: Mark Brown Cc: bug-make@gnu.org Subject: Re: win32 compilation of make 4.0 source code‏ On Sun, 2014-01-26 at 16:22 -0800, Mark Brown wrote: That example method is a device

Re: win32 compilation of make 4.0 source code

-Original Message- From: Philip Guenther Sent: Monday, January 27, 2014 1:34 PM To: Mark Brown Cc: Paul Smith ; bug-make Subject: Re: win32 compilation of make 4.0 source code (Dang it: gmail treats control-enter as "send"...) [Gmail is overrated. When I saw I could not f

Re: win32 compilation of make 4.0 source code

-Original Message- From: Philip Guenther Sent: Monday, January 27, 2014 1:34 PM To: Mark Brown Cc: Paul Smith ; bug-make Subject: Re: win32 compilation of make 4.0 source code (Dang it: gmail treats control-enter as "send"...) [Gmail is overrated. When I saw I could not f

Re: win32 compilation of make 4.0 source code‏

-Original Message- From: Paul Smith Sent: Monday, January 27, 2014 8:57 PM To: Mark Brown Cc: bug-make@gnu.org Subject: Re: win32 compilation of make 4.0 source code? On Mon, 2014-01-27 at 09:59 -0800, Mark Brown wrote: First, let me request that you include the question posed to you

Re: win32 compilation of make 4.0 source code

On Mon, Jan 27, 2014 at 11:05 PM, Mark Brown wrote: From: Paul Smith Sent: Monday, January 27, 2014 8:57 PM ... ifneq ($(filter else-if,$(.FEATURES)),else-if) $(error Version $(MAKE_VERSION) does not support else-if) endif Are you saying that this statement can be placed outside of a

Problem with ifeq/gmake & HPUX 11.00

I am using the hpux ported/pre-compiled gmake, version 3.77 under HPUX 11.00, and I am running into some unexpected behaviour. Any help would be appreciated. I have a Pattern rule defined, and within that pattern rule, I need to check for the existance of another file, and slightly change the "

HP-UX 64 bit bug

stributions. Having had a cursory look with a debugger on the 64 bit machine it seems that the rules are corrupt before the parsing operation is completed. Any assistance would be appreciated. If any further information is required please contact me. Mark Syms Software Engineer Citrix Systems (Research and Development) Ltd +44 1223 568 953 [EMAIL PROTECTED]

RE: HP-UX 64 bit bug

Sorry folks false alarm. It seems that the Imake that generated the makefiles that GNU make died on was the culprit as it wasn't being built correctly for some reason and so generated bad rules. Regards, Mark Syms > -Original Message- > From: Mark Syms > Sent:

target/dependants with equal mtime

e to do the update when it sees the date of the target as being equal to the date of the dependants. There could be undesirable side-effects of my change, or I might not have changed exactly what I thought I did, but it made "make" behave as I expec

Feature Request: ignore @'s in rules

Ignoring the @ (command echo suppressor) during make debugging would be very handy. I can't find a documented option to do so. cheers -mark -- Mark Frazer <[EMAIL PROTECTED]> ___ Bug-make mailing list [EMAIL PROTECTED] http://m

--print-directory doesn't work as documented

ame as it is documented? Thanks, Mark Sheppard, Climax Brighton. ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make

target fails to evaluate

make is failing to evaluate a target ".INIT" which is intended to fetch required files. It is also failing to evaluate the environment to determine suitable host os/version: [mjaffe@taylorws] ~/Kernel> uname -r 5.7 [mjaffe@taylorws] ~/Kernel> grep Solaris /etc/release | awk '{ print $3 }' 8/9

Memory leak

hen I put the tests in a bash script and run that script repeatedly, I got clean output every time. make check was producing garbage every time. If anyone there is a KDE hacker, you should be able to reproduce by running make check in kdepim/karm HEAD. Regards,

Make 3.80 & 3.81: system call failure on Cray t3E

-3.81beta2 build generated just one: CC-167 cc: WARNING File = function.c, Line = 1612 Argument of type "unsigned int *" is incompatible with parameter of type "int *". fold_newlines (buffer, &i); ^ Total warnings de

.IGNORE: target doesn't work (with fix)

I was trying to determine why this Makefile: thing: exit 1 .IGNORE: thing all: thing still fails, even with a fresh source build: $ ./make -f /tmp/Makefile all exit 1 make: *** [thing] Error 1 A bit of code diving turne

[bug #54529] [Makefile:5: foobar] Segmentation fault

ens on CentOS 7.3, but on latest Ubuntu, does not happen. I am hoping that this is merely a matter of different timing and the bug is really present on all OS and a person sufficiently familiar with the code can see it from the above description.

[bug #54529] [Makefile:5: foobar] Segmentation fault

Follow-up Comment #3, bug #54529 (project make): OK, the only system for which this bugs actually shows up, is work build server, and unfortunately, the IT guy does not know where the cores are, and gdb is not working. Let me talk to him about fixing gdb and I will get back to you what I find fro

Re: [bug #54529] [Makefile:5: foobar] Segmentation fault

does crash, I am willing to edit the makefile any way you like and execute any commands you want, so you can zero in on the bug.   But myself I reached the end of the time that I can devote to my own research on this, given the knowledge I possess.   Mark From: Brian Vandenberg To: Cc:

Re: [bug #54529] [Makefile:5: foobar] Segmentation fault

Then why does the error say "make: ***" ?  Shouldn't Make be more robust and assertive in such a case, if a child crashes, to inform the user that it is not Make code?   From: Andreas Schwab To: Mark Galeck ; psm...@gnu.org; bo...@kolpackov.net; bug-make@gnu.org Sent:

Re: [bug #54529] [Makefile:5: foobar] Segmentation fault

y Make bug".   From: Paul D. Smith To: Henrik Carlqvist ; Mark Galeck ; Paul D. Smith ; Martin Dorey ; bo...@kolpackov.net; bug-make@gnu.org Sent: Monday, August 20, 2018 11:33 AM Subject: [bug #54529] [Makefile:5: foobar] Segmentation fault Update of bug #54529 (project make):          

Re: [bug #54529] [Makefile:5: foobar] Segmentation fault

I see, thank you Paul this is very helpful.  I know unfortunately this is going to happen to some of my users, and I don't want them to blame me :)  All these comments I will be able to give them some idea what the problem was.   From: Paul Smith To: Mark Galeck ; Andreas S

[bug #56446] Make shouldn't be running eval when expanding variables for export

URL: Summary: Make shouldn't be running eval when expanding variables for export Project: make Submitted by: mark_galeck0 Submitted on: Thu 06 Jun 2019 01:47:17 AM UTC Severity: 3 - N

AmigaOS support

Why are you dropping support for the AmigaOS in the next release of GNU ? Hopefully you will reconsider ? Kind regards Mark Sealey

bug with Windows interface: echo. in command only works when redirected

hat the results are the same either way. If it's visible to the user, as it is in this case, then there's a bug in the fast path processing. " (end of quotes from Paul) Mark ___ 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

Follow-up Comment #15, bug #712 (project make): Would it be possible to have a special target .NULL_DELIMITED_LISTS to tell Make to use the null character as the list separator instead of whitespace? That way we keep 100% backward compatability and also provide a simple way to support whitespace