[bug #65759] handling of "-" and "--" on command line

Follow-up Comment #2, bug #65759 (group make): - is a valid filename. i think, everybody would be better off, with one and only one syntax of having make read from stdin. ___ Reply to this item at:

[bug #60736] Introduce "Circular <- dependency dropped." for .EXTRA_PREREQS deps.

Follow-up Comment #5, bug #60736 (group make): Attached an alternative patch to https://savannah.gnu.org/bugs/index.php?65739. ___ Reply to this item at:

Re: Treat "Circular dependency...dropped" as a hard error instead?

On Wed, May 8, 2024 at 2:04 PM JZB wrote: > > I have a GNU make-based build system wherein I would like for any/all > GNU make-detected circular dependencies to be treated as a hard error, > i.e., fail [immediately], rather than a "dropped and we go on without > it..." situation. > > Is there a

[bug #65739] Add warnings circular-dep and circular-extra-dep.

Follow-up Comment #2, bug #65739 (group make): Here is an example $ cat makefile hello: hello $ make make: circular hello <- hello dependency dropped make: Nothing to be done for 'hello'. $ make --warn=circular-dep:ignore make: Nothing to be done for 'hello'. $ make --warn=circular-dep:error

[bug #65739] Add warnings circular-dep and circular-extra-dep.

Additional Item Attachment, bug #65739 (group make): File name: sv65739_circular_dep_warn_part1.diff Size: 6KiB File name: sv65739_circular_dep_warn_part2.diff Size: 6KiB

[bug #65739] Add warnings circular-dep and circular-extra-dep.

Follow-up Comment #1, bug #65739 (group make): Patch sv65739_circular_dep_warn_part1.diff adds warning circular-dep. This warning controls how makes handles circular dependencies. The behavior is to silently drop the dependency, print a message or print a message and exit with an error code. The

[bug #65739] Add warnings circular-dep and circular-extra-dep.

Status: None ___ Follow-up Comments: --- Date: Tue 14 May 2024 01:40:55 AM UTC By: Dmitry Goncharov . ___ Reply to thi

Re: Treat "Circular dependency...dropped" as a hard error instead?

On Wed, May 8, 2024 at 2:04 PM JZB wrote: >... perhaps a command line option or a ".CIRCULARERROR:" rule > or some way to allow this to be turned on by those who need it? There is currently no mechanism (option or otherwise) to fail on a circular dependency. On top of that, there are situations

Re: idea: make --show-interpretation

On Mon, May 6, 2024 at 8:26 PM Dan Jacobson wrote: > Have a command that reads in a makefile and outputs the makefile saying > what each part evaluated to. i'd use -p and -n switches. regards, Dmitry

[bug #65685] Submake starts its own jobserver when its recipe contains $(MAKE) $(MFLAGS)

Follow-up Comment #3, bug #65685 (group make): > The way I remember it is that if we see a valid jobserver-auth argument, we ignore the value of -j. My understanding was that we ignore -j that comes from MAKEFLAGS, we still honor -j specified on the command line. > I wonder if we should

[bug #65685] Submake starts its own jobserver when its recipe contains $(MAKE) $(MFLAGS)

Follow-up Comment #1, bug #65685 (group make): Make adds '-j' to MAKEFLAGS and MFLAGS when -j is specified on the command line. When MFLAGS that contains -j is expanded in a recipe, the submake gets -j as a command line switch. This causes submake to start its own jobserver and the submake no

[bug #65685] Submake starts its own jobserver when its recipe contains $(MAKE) $(MFLAGS)

Additional Item Attachment, bug #65685 (group make): File name: sv65685_part1.diff Size: 23KiB File name: sv65685_part2.diff Size: 5KiB

[bug #65685] Submake starts its own jobserver when its recipe contains $(MAKE) $(MFLAGS)

: None Triage Status: None ___ Follow-up Comments: --- Date: Sat 04 May 2024 08:57:53 PM UTC By: Dmitry Goncharov . ___

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

Follow-up Comment #4, bug #65588 (group make): Indeed. Thank you. job.c changed. Paul, do you think we can switch to git branches? i can maintain a branch until merge. i suspect, working with a branch can be easier, than if i attach different versions of a patch.

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

Follow-up Comment #2, bug #65588 (group make): sv65588_part1.diff and sv65588_part2.diff fix the buffer overflow. Make (with sv65588_part1.diff and sv65588_part2.diff applied) behaves differently in oneshell mode compared to when .ONESHELL is not specified. Specifically when .ONESHELL is not

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

Additional Item Attachment, bug #65588 (group make): File name: sv65588_part3.diff Size: 5KiB AGPL NOTICE These attachments are served by Savane. You can download the corresponding source code of Savane

Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64

On Fri, Apr 19, 2024 at 1:42 PM Paul Smith wrote: > The main advantages to alloca are twofold: > > 1) efficiency for small local buffers, which GNU Make uses a lot. > > 2) simplification of the code because you don't have to track this > memory and ensure it's freed regardless of how the function

[bug #65596] Test for let function not available in .FEATURES

Follow-up Comment #2, bug #65596 (group make): Other functions are not present in .FEATURES as well. There is really only guile. ___ Reply to this item at:

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

Follow-up Comment #1, bug #65588 (group make): A buffer overflow occurs in oneshell mode when shellflags contains characters special to shell. $ cat makefile .ONESHELL: .SHELLFLAGS:=hello' all:;: $ make Aborted (core dumped) In oneshell mode construct_command_argv_internal wants to store in

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

Additional Item Attachment, bug #65588 (group make): File name: sv65588_part1.diff Size: 5KiB File name: sv65588_part2.diff Size: 104KiB

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

: None ___ Follow-up Comments: --- Date: Sat 13 Apr 2024 02:13:34 PM UTC By: Dmitry Goncharov . ___ Reply to this item at:

Re: A question about submitting a new source code file

intending to include that file to a library of mine which is released under the bsd license. Usually, souch source code file would contain something like /* * Copyright (c) 2017 Dmitry Goncharov * * Distributed under the BSD License. * (See accompanying file COPYING). */ Do i understand it

A question about submitting a new source code file

Good morning. Paul, i'd like to contribute another bugfix which involves a brand new source code file. i will assign the ownership to fsf, if needed. However, i'd like to be able to use that source file in my other projects, which are not gpl. i have seen other gnu projects including public

Re: A question about hasing in idutils

> It should be easy to fix: swap the bytes in sum_get_unaligned_32. Thanks for the pointer, Andreas. Will try it out. regards, Dmitry

Re: A question about hasing in idutils

Thank you for a quick response, Greg. On Tue, Mar 26, 2024 at 4:56 PM Greg McGary wrote: > The code makes no effort to be endian-independent because it is written > for in-memory hashing on a uniprocessor or homogeneous multiprocessor. Do you know of a specific difficulty of making that hashing

A question about hasing in idutils

Good morning. The hash table from id utils from imported to gnu make. This hash table hashes the same string to different brackets on little and big endian. Can you please shed some light why there needs to be this difference in hashing on little and big endian? regards, Dmitry

[bug #65438] Sort print-targets output.

Follow-up Comment #5, bug #65438 (group make): > Regarding the hashing vs. endianness, I don't know. What do you think of changing hashing to produce the same result on little and big endian? > Regarding sorting, doesn't this basically mean just using strcmp (or a small > wrapper around it)

[bug #65438] Sort print-targets output.

Follow-up Comment #3, bug #65438 (group make): > I doubt most users will be able to map the output they see onto the input make reads except in simple situations. When you start having lots of include files etc. it becomes hard to follow. i was looking for some useful simple deterministic

[bug #65438] Sort print-targets output.

Additional Item Attachment, bug #65438 (group make): File name: sv65438_fix.diff Size:6 KB File name: sv65438_test.diff Size:3 KB

[bug #65438] Sort print-targets output.

Follow-up Comment #1, bug #65438 (group make): Sort print-targets output. print-targets prints the targets in the order they ended up hashed in the table. The hashing routine hashes differently on big and little endian machines. The result is that the test fails on big endian machines. This is

[bug #65438] Sort print-targets output.

: None ___ Follow-up Comments: --- Date: Sat 09 Mar 2024 03:34:40 AM UTC By: Dmitry Goncharov . ___ Reply to this item at:

[bug #65360] Extend -p output with export status of each variable.

Follow-up Comment #6, bug#65360 (group make): test3 is not very useful, though, because '/hello/' will match both 'hello' and 'export hello'. ___ Reply to this item at:

[bug #65360] Extend -p output with export status of each variable.

Additional Item Attachment, bug#65360 (group make): File name: sv65360_fix3.diff Size:1 KB File name: sv65360_test3.diff Size:3 KB

[bug #65360] Extend -p output with export status of each variable.

Follow-up Comment #5, bug#65360 (group make): An alternative to fix2 can be printing "export" when a variable is exported regardless of the defaults, even for MAKEFLAGS, etc. So, here is patch 3 that does that. ___ Reply to this item at:

[bug #65360] Extend -p output with export status of each variable.

Follow-up Comment #4, bug#65360 (group make): > As for export, would it be better to use the make syntax for this Sure. i attached sv65360_fix2.diff and sv65360_test2.diff. The output is make syntax $ cat makefile hello=world all:; $ ~/src/gmake/make//l64//make -r -p |grep -B1 hello #

[bug #65360] Extend -p output with export status of each variable.

Additional Item Attachment, bug#65360 (group make): File name: sv65360_fix2.diff Size:1 KB File name: sv65360_test2.diff Size:3 KB

[bug #65359] submake might will lose variable values if their names contain special char

Follow-up Comment #3, bug#65359 (group make): Exporting a make variable makes it available for shell in recipes. Removal of a semicolon allows make to avoid shell. Instead makes calls posix_spawn or fork and exec. ___ Reply to this item

[bug #65360] Extend -p output with export status of each variable.

Additional Item Attachment, bug#65360 (group make): File name: sv65360_fix.diff Size:1 KB File name: sv65360_test.diff Size:4 KB

[bug #65360] Extend -p output with export status of each variable.

Follow-up Comment #1, bug#65360 (group make): This patch has -p print export status, special and conditional flags of each variable. $ ls makefile $ cat makefile hello?=one all:; $ ~/src/gmake/make/l64/make -rp |grep -B1 -w MAKEFLAGS # makefile special export MAKEFLAGS = pr Here make prints

[bug #65360] Extend -p output with export status of each variable.

Triage Status: None ___ Follow-up Comments: --- Date: Sat 24 Feb 2024 02:42:51 PM UTC By: Dmitry Goncharov . ___ Reply to thi

[bug #65324] Fix crash in disable_builtins.

Additional Item Attachment, bug#65324 (group make): File name: sv65324.diff Size:1 KB AGPL NOTICE These attachments are served by Savane. You can download the corresponding source code of Savane at

[bug #65324] Fix crash in disable_builtins.

Follow-up Comment #1, bug#65324 (group make): Make crashes when -r and MAKEFLAGS= are specified on the command line. On startup make begins to process command line arguments. During processing of "MAKEFLAGS=" make calls reset_makeflags, which in turn calls disable_builtins, which

[bug #65324] Fix crash in disable_builtins.

: None ___ Follow-up Comments: --- Date: Sat 17 Feb 2024 04:27:47 AM UTC By: Dmitry Goncharov . ___ Reply to this item at: <https://savanna

[bug #65323] Functions/shell test 22 causes ksh to crash.

Additional Item Attachment, bug#65323 (group make): File name: sv65323.diff Size:0 KB AGPL NOTICE These attachments are served by Savane. You can download the corresponding source code of Savane at

[bug #65323] Functions/shell test 22 causes ksh to crash.

Follow-up Comment #1, bug#65323 (group make): functions/shell/t022.mk crashes certain shells. E.g. when ksh is used as /bin/sh. That's the test with make exporting a variable whos name is 40K characters long. I tried using perl as a shell, but perl exits with an error message. The patch in the

[bug #65323] Functions/shell test 22 causes ksh to crash.

: None ___ Follow-up Comments: --- Date: Sat 17 Feb 2024 02:50:44 AM UTC By: Dmitry Goncharov . ___ Reply to this item at:

[bug #63840] make allows match-anything rules to match files with the default suffixes

Follow-up Comment #5, bug#63840 (group make): > Sorry for the delay in examining this bug. Thank you for looking at this. ... > However, I tend to agree with you that this is perhaps too much "inside baseball" for the default behavior. i also think, this is too much to be useful. E.g. in

Re: Behavior change related to MAKEFLAGS and recursive make in version 4.4.1

On Thu, Jan 25, 2024 at 12:39 PM Ouellette, Paul wrote: > > Hello, > > Consider the following makefiles: > $ cat Makefile > MAKEFLAGS+=VAR=foo > all: > $(info make VAR=$(VAR)) > @echo "env VAR=$$VAR" > $(MAKE) -C lib > $ cat lib/Makefile > all: > @echo "env

[bug #65211] Fix load and loadapi tests.

Additional Item Attachment, bug#65211 (group make): File name: sv65211.diff Size:1 KB AGPL NOTICE These attachments are served by Savane. You can download the corresponding source code of Savane at

[bug #65211] Fix load and loadapi tests.

Follow-up Comment #1, bug#65211 (group make): load and loadapi tests fail when compiler complains about unused variables. E.g. $ cat work/features/load/t004.diff *** t004.base Thu Jan 25 17:30:36 2024 --- t004.logThu Jan 25 17:30:36 2024 *** *** 1,2 --- 1,10

[bug #65211] Fix load and loadapi tests.

: None ___ Follow-up Comments: --- Date: Thu 25 Jan 2024 10:39:03 PM UTC By: Dmitry Goncharov . ___ Reply to this item at: <https://savanna

Re: New conditional assignment facility

On Mon, Jan 22, 2024 at 8:16 AM Paul Smith wrote: > I don't understand the point you are making about +!=. If all new operators behave the same as +=, when the variable exists, then +!= is not needed, because +!= would do the same as +=$(shell ...). Based on your explanations, it looks like you

Re: Segmentation Fault on Exported Resursively Expanded Variable

On Tue, Jan 16, 2024 at 1:21 PM Henrik Carlqvist wrote: > > On Tue, 16 Jan 2024 06:59:30 + > MIAOW Miao wrote: > > if ((*ep)[nl] == '=' && strncmp (*ep, v->name, nl) == 0) > > Looking at that line, the rather obvious fix would be to change it to: > > if (strncmp (*ep, v->name, nl) == 0 &&

Re: New conditional assignment facility

On Sun, Jan 21, 2024 at 11:17 AM Paul Smith wrote: > I think you wrote that wrong: I think you mean "otherwise +:= behaves > the same as +="... ? You are right. Let us clarify the goal of these enhancements? i assumed that the goal of these enhancements was to allow code like hello+:=$(world)

Re: New conditional assignment facility

On Thu, Jan 11, 2024 at 7:55 AM Paul Smith wrote: > So the new confusion becomes, what happens if you use "+" to append to > an existing variable that has a different type? > > Due to decades of history (and, to be honest, significant technical > incentive), we have to say that in this case: > >

[bug #64822] Fix appending to a pattern specific variable.

Follow-up Comment #6, bug#64822 (group make): Tested on linux, sunos and aix, 64 and 32 bits. ___ Reply to this item at: ___ Message sent via Savannah

[bug #64822] Fix appending to a pattern specific variable.

Follow-up Comment #5, bug#64822 (group make): Paul, i attached fix2 and test2. fix2 is split into 2 parts to ease review. Should be applied in order part1 before part2. Thanks for review. ___ Reply to this item at:

[bug #64822] Fix appending to a pattern specific variable.

Additional Item Attachment, bug#64822 (group make): File name: sv64822_fix2_part1.diffSize:9 KB File name: sv64822_test2.diff Size:9 KB

Re: Segmentation Fault on Exported Resursively Expanded Variable

On Mon, Jan 15, 2024 at 9:02 AM MIAOW Miao wrote: > Here is a Makefile that can reproduce the segmentation fault: > > THIS_LONG_VARIABLE_NAME_PREDUCE_THE_ERROR= $(shell echo hello) > export THIS_LONG_VARIABLE_NAME_PREDUCE_THE_ERROR > > all: ; echo "abc" Thank you for your report. A added a fix

[bug #65172] Fix a buffer overrun on a variable with a long name.

Follow-up Comment #1, bug#65172 (group make): A user reported a buffer overflow on a variable with a long name. Here is a fix. [SV 65172] Fix a buffer overrun on a variable with a long name. * src/expand.c (recursively_expand_for_file): Fix a buffer overrun. *

[bug #65172] Fix a buffer overrun on a variable with a long name.

: None ___ Follow-up Comments: --- Date: Tue 16 Jan 2024 10:43:18 PM UTC By: Dmitry Goncharov . ___ Reply to thi

Re: Segmentation Fault on Exported Resursively Expanded Variable

On Mon, Jan 15, 2024 at 9:02 AM MIAOW Miao wrote: > Here is a Makefile that can reproduce the segmentation fault: > > THIS_LONG_VARIABLE_NAME_PREDUCE_THE_ERROR= $(shell echo hello) > export THIS_LONG_VARIABLE_NAME_PREDUCE_THE_ERROR > > all: ; echo "abc" > > Commands log: > > user@fedora:~$ make >

Re: Handling of MAKEFLAGS

On Wed, Jan 10, 2024 at 5:46 PM Paul Smith wrote: > > On Wed, 2024-01-10 at 17:20 -0500, Dmitry Goncharov wrote: > > Investigating why I discovered the issue was as I mentioned below; once > we have set the flag for -e (the env_overrides global variable) there's > no way to u

Re: Handling of MAKEFLAGS

On Tue, Jan 9, 2024 at 5:35 PM Paul Smith wrote: > Hi Dmitry; Good morning, Paul. > As an example, for the -e change I experimented with simply going > through the variable database and switching the origin from o_env to > o_env_override or vice versa. Do you mean an alternative fix for

[bug #64822] Fix appending to a pattern specific variable.

Follow-up Comment #4, bug#64822 (group make): Paul, please do not apply the attached patch. I prepared a more extensive test and another patch, to cover more cases. Going to attach the new patch in a few days. ___ Reply to this item at:

[bug #64822] Fix appending to a pattern specific variable.

Follow-up Comment #3, bug#64822 (group make): Rob, that's right. The patch fixes both. In fact, this bug report is a duplicate of https://savannah.gnu.org/bugs/?36486. ___ Reply to this item at:

[bug #65006] Implement second expansion of .EXTRA_PREREQS.

Follow-up Comment #2, bug#65006 (group make): Tested 32 and 64 bit on linux, sun and aix. ___ Reply to this item at: ___ Message sent via Savannah

Re: Surprising pattern matching and .EXTRA_PREREQS behaviours

On Mon, Nov 20, 2023 at 8:37 AM Daniel Gerber wrote: > 1. Second expansion is not applied to .EXTRA_PREREQS Thanks for your report. You can find a patch here https://savannah.gnu.org/bugs/index.php?65006. > 2. Setting .EXTRA_PREREQS as pattern-specific variable is not supported A couple of

[bug #65006] Implement second expansion of .EXTRA_PREREQS.

Follow-up Comment #1, bug#65006 (group make): The patch in the attachment implements second expansion of the value of .EXTRA_PREREQS, along with a test. The origin report is here https://lists.gnu.org/archive/html/bug-make/2023-11/msg00018.html.

[bug #65006] Implement second expansion of .EXTRA_PREREQS.

Additional Item Attachment, bug#65006 (group make): File name: sv65006.fixSize:2 KB File name: sv65006.test Size:1 KB

[bug #65006] Implement second expansion of .EXTRA_PREREQS.

: None ___ Follow-up Comments: --- Date: Sun 10 Dec 2023 12:44:15 AM UTC By: Dmitry Goncharov . ___ Reply to this item at:

Re: Bug with $(info xxx) in 4.2.1

On Tue, Dec 5, 2023 at 12:01 AM Aaron Williams wrote: > What is happening is I will get the error: > *** recipe commences before first target. Stop. > At the line with $(info xxx) unless I do not precede it with a tab. This error is expected. A tab precedes a recipe. It does not matter what

[bug #64964] GNU Make deletes intermediate targets that are pattern-rule dependancies

Follow-up Comment #1, bug #64964 (project make): The rules in this example 'foo%: foo%.txt' and 'foo%.txt: foo%.sh' are implicit. Implicit rules can be specified in the makefile. Make's behavior is correct. ___ Reply to this item at:

[bug #64886] order-only prerequisite on a .PHONY line makes prerequisite "unmakeable"

Follow-up Comment #4, bug #64886 (project make): Order-only beats phony. If a target depends on an order-only prerequisite, then this prerequisite does not cause the target to be updated, whether this prerequisite is phony or not. > i guess only issue might be, "should .PHONY: give an error for

[bug #64886] order-only prerequisite on a .PHONY line makes prerequisite "unmakeable"

Follow-up Comment #1, bug #64886 (project make): The described behavior is expected and has nothing to do with order-only. The manual contains the following The implicit rule search (see Using Implicit Rules) is skipped for .PHONY targets. You need an explicit rule for file.elc.

Re: [bug #64571] Add option to print targets

On Wed, Nov 1, 2023 at 10:26 AM Tim Murphy wrote: > Perhaps make could do with some sort of plugin mechanism? I know it has the > load keyword within makefiles but I'm not sure if functions have access to > enough global state to e.g. print out a list of targets. Currently there is no

Re: Possible bug with pattern-specific variables

On Wed, Sep 27, 2023 at 9:33 AM Markus F.X.J. Oberhumer wrote: > Very stange GNU make behaviour with pattern-specific variables - note Thank you for your report. i attached a fix here https://savannah.gnu.org/bugs/index.php?64822 regards, Dmitry

[bug #64822] Fix appending to a pattern specific variable.

Additional Item Attachment, bug #64822 (project make): File name: sv64822_test.diff Size:9 KB File name: sv64822_fix.diff Size:3 KB

[bug #64822] Fix appending to a pattern specific variable.

Follow-up Comment #1, bug #64822 (project make): Markus Oberhumer reported a bug. Appending to a pattern specific variable produces an incorrect value in the presence of a command line definition or an env override of the variable. $ ls makefile $ cat makefile al%: hello+=pattern all:; $(info

[bug #64822] Fix appending to a pattern specific variable.

: None ___ Follow-up Comments: --- Date: Fri 27 Oct 2023 12:50:37 AM UTC By: Dmitry Goncharov . ___ Reply to this item at:

[bug #64803] Fix origin of variables from env when -e is set.

Additional Item Attachment, bug #64803 (project make): File name: sv64803_fix_part1.diff Size:3 KB File name: sv64803_fix_part2.diff Size:14 KB

[bug #64803] Fix origin of variables from env when -e is set.

Follow-up Comment #1, bug #64803 (project make): Variables inherited from env have incorrect origin 'environment' when -e is set and the makefile does not modify the variable. $ ls makefile $ cat makefile $(info at parse time hello=$(hello), origin = $(origin hello)) all:; $(info at build time

[bug #64803] Fix origin of variables from env when -e is set.

: None ___ Follow-up Comments: --- Date: Sat 21 Oct 2023 09:19:42 PM UTC By: Dmitry Goncharov . ___ Reply to this item at:

[bug #64746] Exponential Runtime in make 4.4.1 when export is used

Follow-up Comment #1, bug #64746 (project make): VAR_1 is a recursively expanded variable. When make defines this variable, the value is set to string '$(shell echo 1)'. No subshell is spawned at this time. Each time make expands this variable, make spawns a shell and has the shell execute 'echo

Re: Exponential Runtime in make 4.4.1 when export is used

On Wed, Oct 4, 2023 at 6:09 PM Till Backhaus wrote: > This rather short Makefile shows exponential runtime depending on the number > of variables. > VAR_1 ?= $(shell echo 1) ... VAR_1 is a recursively expanded variable. When make defines this variable, the value is set to string '$(shell echo

Re: Static pattern rules with more than one '%'

On Tuesday, August 29, 2023, Alejandro Colomar wrote: > Hi Paul, > > On 2023-08-29 14:45, Paul Smith wrote: > > On Tue, 2023-08-29 at 11:32 +0200, Alejandro Colomar wrote: > >> Am I missing something? Is something like that allowed anyhow? > > > > Multiple "%" are allowed, in that they won't

Re: MAKEFLAGS=-r

On Wed, Jul 19, 2023 at 4:36 PM Jeffrey Walton wrote: > SUFFIXES does not seem to work too well. 'make -d' still shows all the > extra noise. For example, I added to the top of my GNUmakefile: > >.SUFFIXES: .h .c .cpp .S .o > > I still see: > > $ make -d -f GNUmakefile ... > Trying implicit

Re: MAKEFLAGS=-r

On Mon, Jul 17, 2023 at 5:45 AM Bruno Haible wrote: > And finally, MAKEFLAGS is not even mentioned in the main index of the GNU Make > documentation [5], and only regarding "recursion" in the Variables index [6]. 5.7.3 contains "The MAKEFLAGS variable can also be useful if you want to have

Re: MAKEFLAGS=-r

On Mon, Jul 17, 2023 at 10:47 AM David Boyce wrote: > > Everything else aside, there's a profound difference between MAKEFLAGS=-r and > MAKEFLAGS+=-r. The latter is far less destabilizing. In a relatively fresh make (make-4.0 or later) setting MAKEFLAGS=-r in the makefile takes effect and other

Re: disabling the built-in rules

On Mon, Jul 17, 2023 at 2:41 PM Alejandro Colomar wrote: > MAKEFLAGS += --no-builtin-variables If your makefiles are supposed to work on systems other than linux (still with gnu make), then you may need built-in variables. These variables contain different values on different systems. e.g.

Re: MAKEFLAGS=-r

On Mon, Jul 17, 2023 at 5:45 AM Bruno Haible wrote: > So I wondered whether I should add this variable definition in the Makefile.am files of my GNU packages. i think, that would be good. > "you should be sure not to include any options that will drastically >affect the actions of make"

Re: wildcard and globstar (was: GNU make troubleshooting)

On Sun, Jul 16, 2023 at 4:59 PM Alejandro Colomar wrote: > I'm still interested in globstar support, though. It would make that > line shorter and more robust. Maybe you could add an option > --glob=globstar or similar to enable support. gmake does not keep its own impl of glob. It uses a

Re: wildcard and globstar (was: GNU make troubleshooting)

On Sun, Jul 16, 2023 at 10:49 AM Alejandro Colomar wrote: > I guess I'd need some kind of globstar support in GNU Make to be able > to use that Do you mean you need to find .mk files in subdirectories at different depth levels? mk:=$(wildcard */*/*.mk */*.mk *.mk) regards, Dmitry

Re: GNU make troubleshooting

Como estas, Alex? On Sun, Jul 16, 2023 at 9:59 AM Alejandro Colomar wrote: > I applied the following patch > Glad you liked it. Rather than `find -type f...` (which is painfully

Re: GNU make troubleshooting

On Sat, Jul 15, 2023 at 5:27 PM Bruno Haible wrote: > I believe these two user goals are so different; they belong in different > chapters. i believe, a good approach to big debug output is to modify the makefile to relieve make from doing redundant work. Once make only does necessary minimal

Re: GNU make troubleshooting

> 1) The title, and what does the user want? i guess, users want make to do the minimal amount of work required to fulfil its duties correctly (e.g. track all dependencies, rebuilds, etc). This patch is not a full-fledged troubleshooting guide. This patch describes how to minimize the work that

Re: GNU make troubleshooting

On Mon, Jul 10, 2023 at 2:32 PM Bruno Haible wrote: >I tried -d a couple of times, and it produced a ton of output, that >was too much for me to make sense of. Probably 10% to 20% of the >developers in general have trace filtering skills, that is, know how >to extract the

[bug #64428] Document how to simplify debug output.

Follow-up Comment #2, bug #64428 (project make): Paul, please use sv64428_2.diff (the other patch has a typo). ___ Reply to this item at: ___ Message

[bug #64428] Document how to simplify debug output.

Additional Item Attachment, bug #64428 (project make): File name: sv64428_2.diff Size:5 KB ___ Reply to this item at:

[bug #64428] Document how to simplify debug output.

Follow-up Comment #1, bug #64428 (project make): This patch documents how to simplify make debug output. (file #54928) ___ Additional Item Attachment: File name: sv64428.diff Size:5 KB

  1   2   3   4   5   6   7   >