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

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: 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: 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

[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

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

: None ___ Follow-up Comments: --- Date: Sat 15 Jul 2023 03:17:03 PM UTC By: Dmitry Goncharov . ___ Reply to this item at:

[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 #2, bug #64428 (project make): Paul, please use sv64428_2.diff (the other patch has a typo). ___ Reply to this item at: ___ Message

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

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: enhancement: better clarification of search side effects

On Wed, May 31, 2023 at 12:40 PM wrote: > today i had a strange problem with a long used makefile (GNU Make 4.3). > It found a file called "all.sh" and did a "cat all". That's not a strange problem. That's the default make behavior. > I use makefile for a long time but that effect happend the

[bug #64295] Detect plugin binary compatibility at load time

Status: None ___ Follow-up Comments: --- Date: Sun 11 Jun 2023 02:36:50 PM UTC By: Dmitry Goncharov . ___ Reply to thi

[bug #64295] Detect plugin binary compatibility at load time

Follow-up Comment #1, bug #64295 (project make): This patch implements make abi versioning for loadable plugins. The proposed patch is binary compatible with existing plugins. This patch allows make to detect if a plugin is binary compatible and exit with an error in the case of a binary

[bug #64295] Detect plugin binary compatibility at load time

Additional Item Attachment, bug #64295 (project make): File name: sv64295_detect_plugin_compat.diff Size:12 KB ___ Reply to this item at:

[bug #64295] Detect plugin binary compatibility at load time

Follow-up Comment #2, bug #64295 (project make): Paul, i see that you introduced a new parameter to the setup function. This new parameter will cause make to crash (if the user is fortunate) or it will cause some undefined behavior otherwise. >From the users point of view the cause will be

[bug #64259] Regression in master: make ignores statements it should not ignore.

: None Triage Status: None ___ Follow-up Comments: --- Date: Sat 27 May 2023 03:33:14 PM UTC By: Dmitry Goncharov . ___

[bug #64259] Regression in master: make ignores statements it should not ignore.

Follow-up Comment #1, bug #64259 (project make): Commit 07fcee35f058a876447c8a021f9eb1943f902534 introduced a regression. The text in NEWS clarifies that the idea was to never consider a line starting with the recipe prefix as a conditional, to ensure make does not confuse recipe lines with

[bug #64185] *** only one 'else' per conditional. Stop. due to else in recipe

Follow-up Comment #11, bug #64185 (project make): > If someone has a thought of something this might break (other than people indenting their conditionals with the recipe prefix) please let me know See https://savannah.gnu.org/bugs/index.php?64259

Re: new feature idea: ingesting processed rulesets

On Tue, May 23, 2023 at 9:07 AM Zoltán Turányi wrote: > If we invoke make on the top makefile, it will compile the two lib{1,2}.o > object files serially. That's because your rule is subs: cd sub1 make cd ../sub2 make Do something

[bug #64259] Regression in master: make ignores statements it should not ignore.

Additional Item Attachment, bug #64259 (project make): File name: sv64259_fix.diff Size:2 KB File name: sv64259_test.diff Size:1 KB

[bug #64185] *** only one 'else' per conditional. Stop. due to else in recipe

Follow-up Comment #1, bug #64185 (project make): The same behavior can be demonstrated with the following makefile ifdef blah junk: else else endif The parser does not perform variable expansion and ignores rule definitions in conditional branches which are not taken to avoid redundant

[bug #64185] *** only one 'else' per conditional. Stop. due to else in recipe

Follow-up Comment #2, bug #64185 (project make): It is also necessary to ignore rule definitions in the branches which are not taken from the point of view of correctness. all: hello.tsk hello=1 ifdef hello hello.tsk:; echo true else hello.tsk:; echo false endif Here, we need the 'echo true'

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: > >

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: 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: 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 &&

[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

[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 #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 #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 #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 #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 #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 #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.

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

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: 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:

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: 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 >

[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. *

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.

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

[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:

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

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.

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

[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 #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

[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 #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.

[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:

[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 #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:

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

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

[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 #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)

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

[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

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

[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

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

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.

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

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

[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 #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.

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

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)

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

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

[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 #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.

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 #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_fix2.diff Size:1 KB File name: sv65360_test2.diff Size:3 KB

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

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.

Additional Item Attachment, bug#65360 (group make): File name: sv65360_fix3.diff Size:1 KB File name: sv65360_test3.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 #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:

Re: [PATCH] Fix biased shuffle by avoiding already "struck" elements

On Wed, Jun 19, 2024 at 5:37 PM Sergei Trofimovich wrote: > Glancing at tests/ all the tests exercise user-facing `make` API. What > would be the best way to validate probabilities? For this type of code like shuffle, i like testing the function itself, directly. Just calling the function in a

Re: [PATCH] Fix biased shuffle by avoiding already "struck" elements

On Fri, Jun 21, 2024 at 10:30 AM Paul Smith wrote: > > On Fri, 2024-06-21 at 09:11 -0400, Dmitry Goncharov wrote: > > i hope, Paul approves adding tests of this nature. > > I have no problems with adding unit tests, as long as we can find a way > to integrate i

Re: [PATCH] Fix biased shuffle by avoiding already "struck" elements

On Tue, Jun 18, 2024 at 5:38 PM Sergei Trofimovich wrote: > After the change probabilities are not as biased: > > 0 1 2 3 > _ _ _ _ > 0 | 24.99 24.99 25.01 25.01 > 1 | 24.99 25.04 24.99 24.99 > 2 | 25.01 25.00 25.00 24.99 > 3 | 25.01

<    1   2   3   4   5   6   7   >