Re: patsubst: Whitespaces are not replaced by spaces | Possible issue in make or the documentation

Hi Marek! Please choose just onee mailing list to ask your question, rather than sending it to multiple lists. Either one would be appropriate for this question IMO. On Wed, 2025-04-30 at 12:15 +, Marek Küthe wrote: > I am currently taking a closer look at the `patsubst` function in > `make

Re: .NOTPARALLEL doesn't seem to work as shown in the documentation

On Thu, 2025-04-24 at 11:45 +0200, Gabriele Santandrea wrote: > Greetings, > I am trying to learn make, going through the documentation and even > writing a repository containing examples copied, extrapolated or > commented from the GNU make docs. > > In Section 5.4.1 when running the .NOTPARALLEL

Re: seg fault with EXTRA_PREREQS

On Tue, Apr 22, 2025 at 8:54 PM Shim Manning wrote: > > Minimal test. Generates a list of 1000 prerequisites. > > list := $(shell for n in $$(seq 1 1000); do echo file_$$n; done) > all: .EXTRA_PREREQS := $(list) > all: > echo "fin" > > And tes making a copy of the table appears to fix it Thank y

Re: seg fault with EXTRA_PREREQS

Minimal test. Generates a list of 1000 prerequisites. list := $(shell for n in $$(seq 1 1000); do echo file_$$n; done) all: .EXTRA_PREREQS := $(list) all: echo "fin" And tes making a copy of the table appears to fix it On Sat, Apr 19, 2025 at 9:26 PM Dmitry Goncharov wrote: > On Fri, Apr 18,

Re: seg fault with EXTRA_PREREQS

On Fri, Apr 18, 2025 at 11:12 PM Shim Manning wrote: > > Seems that using .EXTRA_PREREQS can cause a segfault under the right > conditions. ... > snap_deps > hash_map_arg (loop happens here) > snap_file > expand_extra_prereqs > enter_file > hash_insert_at > hash_rehash (loop no longer valid) >

Re: library of make fragments

Thanks for the feedback. At first glance a merge would make sense to me. I'll play with it some, and contact the author. -Josh On Sun, Apr 6, 2025 at 12:06 AM carl hansen wrote: > > FYI > > https://gmsl.jgc.org/ > GNU Make Standard Library > "The GNU Make Standard Library (GMSL) is a collection o

Re: library of make fragments

and file CC.py reads from file F.txt (and CC.py declares its INPUTS= as described below). Now if you modify file F.txt or CC.py, any rule that runs BBB.py will automatically be re-run in the correct order when you use make, even if you didn't directly edit BBB.py. In tests with over 1000 files the

Re: library of make fragments

also of interest: https://github.com/Trepan-Debuggers/remake

Re: library of make fragments

On Sun, Apr 6, 2025 at 8:28 AM Bahman Movaqar wrote: > > Hey all 👋️ > > Very interesting topic! > > I thought I'd share my own attempt at having a collection of useful utilities > for my Makefiles 😅️ Slightly more on the datastucture side there's the very nice-looking GNU Make Standard Library h

Re: library of make fragments

Hey all 👋️ Very interesting topic! I thought I'd share my own attempt at having a collection of useful utilities for my Makefiles 😅️ https://github.com/bahmanm/bmakelib _The minimalist Make standard library you'd always wished for!_ It's fully tested via the CI pipeline¹ and available as a Dock

Re: library of make fragments

FYI https://gmsl.jgc.org/ GNU Make Standard Library "The GNU Make Standard Library (GMSL) is a collection of functions implemented using native GNU Make functionality that provide list and string manipulation, integer arithmetic, associative arrays, stacks, and debugging facilities. The GMSL is r

Re: library of make fragments

> I was wondering about the possibility of adding, as a feature to make, > the addition of a standard makefile fragments library. I have started > such a library. > https://gitlab.com/enoch247/fracture That is a nice initiative! Regardless if such a work should be included in distributions of GNU

Re: order-only prerequisites themselves get rebuilt when not needed

On Wed, 2025-03-19 at 09:58 -0400, Dmitry Goncharov wrote: > What do you think we should do? I think we should either do nothing and leave it as it is, or try to provide the functionality that Britton is looking for (the behavior in my description). The questions are, is this behavior strictly be

Re: order-only prerequisites themselves get rebuilt when not needed

On Mon, 2025-03-17 at 21:16 -0400, Dmitry Goncharov wrote: > > To build target A: > > - First try to build all NON-ORDER-ONLY prerequisites > > - Compare the modification time of all NON-ORDER-ONLY prerequisites > > - If any NON-ORDER-ONLY prerequisite is newer than A: > >    - Try to build all ORD

Re: Ability to print the make database as json - experimental

> On Mar 22, 2025, at 3:51 PM, Tim Murphy wrote: > > I cannot at the moment see this being added to make proper - at least not for > some time. I don't see why. This seems like useful general-purpose functionality. I would encourage creating a version that can be added & asking to get it ad

Re: Ability to print the make database as json - experimental

On Thu, 20 Mar 2025 at 21:07, David A. Wheeler wrote: > > > > On Mar 18, 2025, at 1:21 PM, Tim Murphy wrote: > > > > I've recently updated and rebased my experimental fork of make with the > branch that dumps the internal database of the makefile to JSON format > files. > > I would *dearly* love

Re: Ability to print the make database as json - experimental

> On Mar 18, 2025, at 1:21 PM, Tim Murphy wrote: > > I've recently updated and rebased my experimental fork of make with the > branch that dumps the internal database of the makefile to JSON format files. I would *dearly* love to have the ability to receive a dump of the makefile database i

Re: order-only prerequisites themselves get rebuilt when not needed

On Wed, Mar 19, 2025 at 5:59 AM Dmitry Goncharov wrote: > > On Tue, Mar 18, 2025 at 8:06 AM Paul Smith wrote: > > I see from the patch: you don't mean "never" you mean, only if the > > prerequisite does not exist will it be updated. > > Right. > > > I agree this preserves probably the most common

Re: order-only prerequisites themselves get rebuilt when not needed

On Tue, Mar 18, 2025 at 8:06 AM Paul Smith wrote: > I see from the patch: you don't mean "never" you mean, only if the > prerequisite does not exist will it be updated. Right. > I agree this preserves probably the most common reason for using OO > prereqs (to create directories) This preserves

Re: Ability to print the make database as json - experimental

I've recently updated and rebased my experimental fork of make with the branch that dumps the internal database of the makefile to JSON format files. It handles more aspects of the database but not all of them. Listing directories still doesn't work yet. I don't have a test set to try it on so it

Re: order-only prerequisites themselves get rebuilt when not needed

On Mon, Mar 17, 2025 at 8:12 AM Paul Smith wrote: > The question we have think carefully about is what sort of backward- > compatibility issues, if any, we could introduce. Are there situations > where people are relying on the current behavior? It is possible that someone relies that running 'm

Re: order-only prerequisites themselves get rebuilt when not needed

On Mon, Mar 17, 2025 at 4:12 AM Paul Smith wrote: > > On Sat, 2025-03-15 at 08:28 -0400, Dmitry Goncharov wrote: > > On Mon, Mar 10, 2025 at 8:12 AM Paul Smith wrote: > > > > > > On Sat, 2025-03-08 at 11:34 -0900, Britton Kerin wrote: > > > > What confuses me is that since the explicitly requeste

RE: order-only prerequisites themselves get rebuilt when not needed

AM To: Cook, Malcolm ; bug-make@gnu.org Subject: Re: order-only prerequisites themselves get rebuilt when not needed The patch attached to the savannah issue Dmitry provided below does include a doc change. I haven't reviewed it yet. Basically the current behavior is: To build target A: -

Re: order-only prerequisites themselves get rebuilt when not needed

ers get up to speed with the proposal??? > > > > From: bug-make-bounces+mec=stowers@gnu.org > Sent: Monday, March 17, 2025 7:10:06 AM > To: bug-make@gnu.org > Subject: Re: order-only prerequisites themselves get rebuilt when not > needed >   > On Sat, 2025-03-15

Re: order-only prerequisites themselves get rebuilt when not needed

get up to speed with the proposal??? Get Outlook for Android<https://aka.ms/AAb9ysg> From: bug-make-bounces+mec=stowers@gnu.org on behalf of Paul Smith Sent: Monday, March 17, 2025 7:10:06 AM To: bug-make@gnu.org Subject: Re: order-only prerequ

Re: order-only prerequisites themselves get rebuilt when not needed

On Sat, 2025-03-15 at 08:28 -0400, Dmitry Goncharov wrote: > On Mon, Mar 10, 2025 at 8:12 AM Paul Smith wrote: > > > > On Sat, 2025-03-08 at 11:34 -0900, Britton Kerin wrote: > > > What confuses me is that since the explicitly requested foo > > > exists and isn't out of date with respect to any n

Re: order-only prerequisites themselves get rebuilt when not needed

On Mon, Mar 10, 2025 at 8:12 AM Paul Smith wrote: > > On Sat, 2025-03-08 at 11:34 -0900, Britton Kerin wrote: > > What confuses me is that since the explicitly requested foo exists > > and isn't out of date with respect to any non-order-only prereqs (in > > the example it doesn't have any) and the

Re: Reporting Security Violations in Software Package

> On Mar 12, 2025, at 11:57 AM, Paul Smith wrote: > > On Wed, 2025-03-12 at 15:05 +, Yao Shuangjie wrote: >> We are cybersecurity researchers from the Hong Kong University of >> Science and Technology. We found several security violations of >> undefined behaviors in GNU make 4.4.1 using o

Re: Reporting Security Violations in Software Package

On Wed, 2025-03-12 at 15:05 +, Yao Shuangjie wrote: > We are cybersecurity researchers from the Hong Kong University of > Science and Technology. We found several security violations of > undefined behaviors in GNU make 4.4.1 using our novel symbolic > execution technique several months ago. Th

Re: trailing comments prevent whitespace removal

On Mon, 2025-03-10 at 12:38 -0800, Britton Kerin wrote: > I would expect make to remove trailing comments and then strip > surrounding white space from variable definitions as usual but it > seems that the comments prevent further stripping: Comments don't prevent stripping; values in assignments

Re: order-only prerequisites themselves get rebuilt when not needed

On Sat, 2025-03-08 at 11:34 -0900, Britton Kerin wrote: > What confuses me is that since the explicitly requested foo exists > and isn't out of date with respect to any non-order-only prereqs (in > the example it doesn't have any) and therefore isn't getting rebuilt, > I wouldn't expect there to be

Re: order-only prerequisites themselves get rebuilt when not needed

On Fri, Mar 7, 2025 at 4:59 AM Paul Smith wrote: > > On Thu, 2025-03-06 at 13:28 -0900, Britton Kerin wrote: > > In this example, I would not expect bar to be updated due to > > actual_source when foo is requested. The timestamp dependency chain > > should be broken between foo and bar and Make s

Re: order-only prerequisites themselves get rebuilt when not needed

On Thu, 2025-03-06 at 13:28 -0900, Britton Kerin wrote: > In this example, I would not expect bar to be updated due to > actual_source when foo is requested.  The timestamp dependency chain > should be broken between foo and bar and Make should be able to > figure that out when handling an explicit

Re: [bug #66870] memory corruption

On Wed, 2025-03-05 at 18:23 -0500, Dmitry Goncharov wrote: > There is a buffer overflow when shellflags contains characters > special to shell, like =. > See https://savannah.gnu.org/bugs/?65588. I got really fed up with the current command line parser and I have a fully-rewritten version that is

Re: Enabling hi-res timestamps on Windows

> From: Jeffrey Walton > Date: Wed, 19 Feb 2025 09:04:27 -0500 > Cc: Eldred HABERT , bug-make@gnu.org > > On Wed, Feb 19, 2025 at 7:41 AM Eli Zaretskii wrote: > > > > It is not that simple. GNU Make uses 'stat' to retrieve the time > > stamp of files, and the Windows implementation of 'stat' re

Re: Enabling hi-res timestamps on Windows

On Wed, Feb 19, 2025 at 7:41 AM Eli Zaretskii wrote: > > > Date: Tue, 18 Feb 2025 22:06:11 +0100 (GMT+01:00) > > From: Eldred HABERT > > > > Hello! > > > > I am having an issue that some versions of Make never stop on a Make file I > > made, but only on Windows. > > https://github.com/ISSOtm/gb-

Re: Enabling hi-res timestamps on Windows

> Date: Tue, 18 Feb 2025 22:06:11 +0100 (GMT+01:00) > From: Eldred HABERT > > Hello! > > I am having an issue that some versions of Make never stop on a Make file I > made, but only on Windows. > https://github.com/ISSOtm/gb-starter-kit/issues/1#issuecomment-1793775226 > I have traced the issue

Re: Negating --no-print-directory

On Mon, 2025-02-10 at 03:40 +0900, Masahiro Yamada wrote: > ifeq ($(SUBMAKE),) > MAKEFLAGS += --no-print-directory > MAKEFLAGS += -rR > all: >     @echo in top: MAKEFLAGS=$(MAKEFLAGS) >     $(MAKE) -w SUBMAKE=1 > else > all: >     @echo in submake: MAKEFLAGS=$(MAKEFLAGS) > endif > > >

Re: The first word in $(MAKEFLAGS) is not a group of short options

On Mon, 2025-02-10 at 02:01 +0900, Masahiro Yamada wrote: > The first word in $(MAKEFLAGS) is not a group of short options. > >     $(MAKE) MAKEFLAGS=--no-print-directory SUBMAKE=1 If you override the value of MAKEFLAGS as a command-line variable assignment, then the value you specified is th

Re: The first word in $(MAKEFLAGS) is not a group of short options

On Sun, Feb 9, 2025 at 12:04 PM Masahiro Yamada wrote: ... > This is no longer true when MAKEFLAGS is set > via the command line. A command line definition of MAKEFLAGS is a bad idea. https://savannah.gnu.org/bugs/?62469 regards, Dmitry

Re: CARLA Simulator installation error

On Sun, Feb 9, 2025 at 12:18 PM Himanshu Pradeep wrote: > > Hello Team > I hope this email finds you well > > I was installing CARLA Simulator, building from source for windows. I am > following all the guidelines shown on the website Windows build - CARLA > Simulator . I am running Make version

Re: [PATCH] Don't filter duplicate -C options

On Tue, 2025-01-21 at 22:00 +0100, Michael Olbrich wrote: > Since c3b39d0654c3 "[SV 62514] Honor command line interface flags", > make incorrectly filters oute multiple -C arguments with the same > directoy string: Oh that's bad. Thanks for the patch!

Re: suggestion: make --version should show .FEATURES

Basile Starynkevitch (13 January 2025 11:51) wrote: > My suggestion is that make --version would show the .FEATURES Perhaps limit that to make -v --version ? Eddy.

Re: Proposition & PATCH: Add a "letrec" builtin function

On Sat, Jan 11, 2025 at 3:40 AM Pete Dietl wrote: > You need a recursive let if you want to be able to define inner functions, > like a helper function. That much I understand, but I cannot come up with many scenarios where that would make sense in Make. Whenever the definition of the inner func

Re: Proposition & PATCH: Add a "letrec" builtin function

Jouke, You need a recursive let if you want to be able to define inner functions, like a helper function. On Mon, Dec 30, 2024, 5:21 AM Jouke Witteveen wrote: > Hi Pete, > > On Thu, Dec 26, 2024 at 7:44 AM Pete Dietl wrote: > > I propose adding a "letrec" builtin to complement the "let" builti

Re: Proposition & PATCH: Add a "letrec" builtin function

Hi Pete, On Thu, Dec 26, 2024 at 7:44 AM Pete Dietl wrote: > I propose adding a "letrec" builtin to complement the "let" builtin. > The "let" builtin does not allow one to define inner functions or > mutually recursive definitions. Can you maybe help me understand why this functionality would be

Re: [RFC PATCH v4 0/3] per-target .ONESHELL with shard recipe fix

On Thu, Dec 26, 2024 at 10:37 AM David A. Wheeler wrote: > > > On Dec 23, 2024, at 7:56 PM, Britton Leo Kerin > > wrote: > > > > Another crack at per-target .ONESHELL. > > > > The major problem with v3 was that the shared struct commands for > > implicit rules, .DEFAULT rules suffix rules etc. c

Re: [RFC PATCH v4 0/3] per-target .ONESHELL with shard recipe fix

> On Dec 23, 2024, at 7:56 PM, Britton Leo Kerin > wrote: > > Another crack at per-target .ONESHELL. > > The major problem with v3 was that the shared struct commands for > implicit rules, .DEFAULT rules suffix rules etc. caused use of .ONESHELL > with any target covered by such a rules to "

Re: [PATCH] Add arithmetic builtin functions

On Mon, 2024-12-09 at 17:18 -0800, Pete Dietl wrote: > Here is a bit of test code I came up with. Do you think this is > necessary and or the right approach for testing with extreme values > of double and long long? I think the idea of setting values in config-flags.pm.in is correct, just to keep

Re: [PATCH] Add arithmetic builtin functions

; +> @echo 0_4 $(add ' . $llong_min . ',1) > +', '', '0_1 1 > +0_2 1 > +0_3 10 > +0_4 ' . Math::BigInt->new($llong_min)->badd(1)->bstr() . ' > +'); > + > +1; > -- > 2.43.0 > > > On Mon, Dec 9, 2024 at 12:50

Re: POSIX question on implicit .o rules

On Thu, 2024-12-19 at 14:08 -0500, Paul Smith wrote: > Technically, make's built-in recipe for .c.o is: Of course here I mean GNU Make, not POSIX make :-/.

Re: POSIX question on implicit .o rules

On Thu, 2024-12-19 at 12:17 -0600, Eric Blake wrote: > Currently GNU make does not conform to the required .c.o inference > rule because it adds a -o option. Technically, make's built-in recipe for .c.o is: $(COMPILE.c) $(OUTPUT_OPTION) $< where OUTPUT_OPTION is set to "-o $@" if GNU Make's co

Re: Bug in GNU make if -j used with very high values

On Wed, 2024-12-18 at 15:29 -0500, Dianne Skoll wrote: > On Debian GNU/Linux 12 with default settings, the command: > >    make -j 7 > > hangs. This is https://savannah.gnu.org/bugs/index.php?66499

Re: [PATCH] Add arithmetic builtin functions

veen wrote: > > > What I remember from the original thread is that we first needed a > > > good proposal. I'm afraid the existence of the implementation > > > suggested now sidesteps the discussion on what functionality is > > > actually desirable. > > >

Re: [PATCH] Add arithmetic builtin functions

do something completely different, then that's what we'll do. No doubt whatever we decide the user interface should be, at least big chunks of this code can be re-used anyway. Hopefully this won't be a shock to Pete :) I agree that the big open question from the previous discussion w

Re: [PATCH] Add arithmetic builtin functions

Jouke, Wed, 20 May 2020 13:42:11 -0400, Paul Smith wrote: > > Another option would be to introduce some new syntax like $(()), > > but that might break existing Makefiles and would probably be more > > work, though it looks cleaner IMO. > No, I don't agree with that. Trying to change the base ma

Re: [PATCH] Add arithmetic builtin functions

On Mon, Dec 9, 2024 at 12:11 AM Paul Smith wrote: > I reviewed the previous (lengthy) email thread before looking at this > patch. I guess you mean the thread that at some point was titled "math expressions" [1]. Was there any conclusion there? At some point it gravitated to a shell/Posix-style e

Re: [PATCH] Add arithmetic builtin functions

Paul, Thanks for the review! 1. I will remove the use of GCC C extensions, the use of the _Generic C11 feature, and the use of compound literals. 2. I do need help getting started on the copyright paperwork though I seem to remember completing this before. At any rate, I will sign it again if nece

Re: [PATCH] Add arithmetic builtin functions

Thanks for this work Pete! I reviewed the previous (lengthy) email thread before looking at this patch. This is a good first crack. There are a few confusing bits and we will need tests added for the various corner cases, and documentation. I can do the docs if you prefer; I usually edit them a

Re: [PATCH] Add arithmetic builtin functions

I apologize for my tardiness in reviewing this patch; it's been a busy few weeks here. On Fri, 2024-11-29 at 12:31 -0800, Pete Dietl wrote: > > Not sure about such inline 'structs'. > > These are called "compound literals" and have been part of C since > C99. > More broadly though, what is the n

Re: [bug #66499] Parameter for option -j seems not to be validated and can cause hangs

On Sun, 2024-12-01 at 17:12 +0100, Henrik Carlqvist wrote: > On Sun,  1 Dec 2024 09:10:04 -0500 (EST) > "Paul D. Smith" wrote: > > F_GETPIPE_SZ will work on Linux but it's not portable (not part of > > POSIX > > fcntl) > > Suggestion: Use F_GETPIPE_SZ as a limit when it does exist, if not, > use

Re: [bug #66499] Parameter for option -j seems not to be validated and can cause hangs

On Sun, 1 Dec 2024 09:10:04 -0500 (EST) "Paul D. Smith" wrote: > F_GETPIPE_SZ will work on Linux but it's not portable (not part of POSIX > fcntl) Suggestion: Use F_GETPIPE_SZ as a limit when it does exist, if not, use some arbitrary big value which usually will be "big enough with a margin". I

Re: [PATCH] Add arithmetic builtin functions

Gisle Vanem wrote: > > +#define generic_math_op(a, b, op) > >\ > > + ((void)sizeof ( > >\ > > + char[__builtin_types_compatible_p (typeof (a), typeof (b)) ? 1 : > > -1]), \ > > + _G

Re: [PATCH] Add arithmetic builtin functions

Pete Dietl wrote: Here I submit to you a patch that adds the following builtin functions to make: `add` (addition), `sub` (subtraction), `mul` (multiplication), `div` (division), `mod` (modulus), `max` (maximum), `min` (minimum), and `abs` (absolute value). The implementation I provide supports

Re: Parallel make across multiple connected systems.

> From: Sean Godsell > Date: Wed, 27 Nov 2024 17:00:27 -0500 > > I was wondering if anyone has any plans to make the actual 'make' command > work across multiple > connected PC systems, via networking of some kind. It could be wireless > networking, ethernet, or even > networking through thund

Re: Parallel make across multiple connected systems.

On Wed, 27 Nov 2024 17:00:27 -0500 Sean Godsell wrote: > I was wondering if anyone has any plans to make the actual 'make' command > work across multiple connected PC systems, via networking of some kind. It > could be wireless networking, ethernet, or even networking through > thunderbolt, usb 4

Re: [RFC PATCH v3 0/1] per-target .ONESHELL support

> On Mon, 2024-11-18 at 12:06 -0900, Britton Leo Kerin wrote: >> This is the cleaned up version that has a flag rather than twiddling >> the global. I think it's all reasonably ready now and if there's any >> possibility of getting it included I'll add tests and documentation. I think this is g

Re: [RFC PATCH v3 0/1] per-target .ONESHELL support

On Mon, 2024-11-18 at 12:06 -0900, Britton Leo Kerin wrote: > This is the cleaned up version that has a flag rather than twiddling > the global.  I think it's all reasonably ready now and if there's any > possibility of getting it included I'll add tests and documentation. I think it's a good idea

Re: '... | Avoiding implicit rule recursion for rule '%/dir: %'. | ...'

' are actually 'ordinal' targets in and each later step is dependent on the earlier one. (Also it would be easy to extend in the future, no worries about step re-numbering.) And to avoid potential name collisions (e.g. the user have to do more than once 'Next') and to accommo

Re: '... | Avoiding implicit rule recursion for rule '%/dir: %'. | ...'

Please ignore. (After shutting down VMs on the computer the build completed. Strange symptom nevertheless...) On Tuesday, November 12th, 2024 at 11:41 PM, WaitronCharm via Bug reports and discussion for GNU make wrote: > Thank you for the patch. I was about to try it out and was following the

Re: '... | Avoiding implicit rule recursion for rule '%/dir: %'. | ...'

Thank you for the patch. I was about to try it out and was following the steps here: https://git.savannah.gnu.org/cgit/make.git/tree/README.git Any idea why the build is stuck at '/usr/bin/msgmerge --update --lang=ga ga.po make.pot'? The 'msgmerge' process just hangs and uses zero CPU. Did stop

Re: '... | Avoiding implicit rule recursion for rule '%/dir: %'. | ...'

On Thu, Nov 7, 2024 at 3:49 AM WaitronCharm via Bug reports and discussion for GNU make wrote: > > all: hello.tsk > > %.tsk: %.o; $(info hello.tsk) > > %.o: %.c %.tsk; $(info hello.c) > Wouldn't this result anyway in a cyclic graph due to '%.tsk'? This is a legal makefile. Make drops the circular

Re: '... | Avoiding implicit rule recursion for rule '%/dir: %'. | ...'

On Wednesday, November 6th, 2024 at 9:51 PM, Dmitry Goncharov wrote: > Maybe the authors had some other reason, but the only reason i can see > today for implicit rules (other than match-anything rules) is > avoidance of infinite recursion in cases like the following > > all: hello.tsk > %.tsk:

Re: '... | Avoiding implicit rule recursion for rule '%/dir: %'. | ...'

>> I am sure there are legitimate cases where recursively (but not >> infinitely) applying pattern rules should be useful. Dmitry Goncharov (6 November 2024 21:51) replied (inter alia): > How do you teach make to allow some, but not infinite recursion? Allow recursion whenever each step takes you

Re: '... | Avoiding implicit rule recursion for rule '%/dir: %'. | ...'

On Tue, Nov 5, 2024 at 8:55 AM WaitronCharm via Bug reports and discussion for GNU make wrote: > Is there any design rationale why 'make' does not like applying the same > pattern rule more than once for the same target? Maybe the authors had some other reason, but the only reason i can see toda

Re: how hard would it be to implement per-target .ONESHELL?

On Thu, 2024-10-31 at 13:44 -0800, Britton Kerin wrote: > Thinking about it again this would be the single biggest upgrade I > can think of for Make for me.  I have so much code strung together > with && \ but it's all in fairly large complex makefiles and there's > no way I'm going to risk global

Re: Idea: Allow some special targets to also be given as prerequisites (foo: .PHONY == .PHONY: foo)

On Thu, Oct 31, 2024 at 9:19 AM David A. Wheeler wrote: > > GNU Make supports a number of special built-in target names > . > > I think it'd be helpful if some special target names could be listed as > *prerequisites* (foo: .PHONY

Re: say which of .PRECIOUS: %.o *.o file.o will actually work

On Fri, 2024-10-11 at 09:45 +, Edward Welbourne wrote: > Paul Smith (10 October 2024 17:56) wrote: > > .PRECIOUS is dangerous and should almost never be needed or used.  > > This danger can be avoided by having a recipe (or the command it > runs) generate the new file under an alternative name

Re: say which of .PRECIOUS: %.o *.o file.o will actually work

Paul Smith (10 October 2024 17:56) wrote: > .PRECIOUS is dangerous and should almost never be needed or used. Its > goal is to prevent make from deleting files automatically when a > recipe fails (for any reason). There are very few, very rare > situations where this is what you want, because it

Re: say which of .PRECIOUS: %.o *.o file.o will actually work

On Thu, 2024-10-10 at 11:45 -0400, Dmitry Goncharov wrote: > There is little benefit to mark files built by static pattern rules > precious,  because static pattern rules do not build intermediate > files. It's a mistake to consider .PRECIOUS in the context of intermediate files. This is a common

Re: say which of .PRECIOUS: %.o *.o file.o will actually work

On Thursday, October 10, 2024, Britton Kerin wrote: > On Wed, Oct 9, 2024 at 4:01 PM Dmitry Goncharov wrote: >> >> On Tue, Oct 8, 2024 at 11:16 PM Dan Jacobson wrote: >> > >> > Manual says: >> > >> >You can list the target pattern of an implicit rule (such as '%.o') >> >as a prerequisite

Re: say which of .PRECIOUS: %.o *.o file.o will actually work

On Tue, Oct 8, 2024 at 7:16 PM Dan Jacobson wrote: > > Manual says: > >You can list the target pattern of an implicit rule (such as '%.o') >as a prerequisite of the special target '.PRECIOUS' to preserve >intermediate files made by implicit rules whose target patterns match >that f

Re: say which of .PRECIOUS: %.o *.o file.o will actually work

Thanks. OK, the manual should say that >> .PRECIOUS: %.o will usually work, >> .PRECIOUS: *.o will never work, (unless the file really has an asterisk in its name) and >> .PRECIOUS: file.o will always work.

Re: say which of .PRECIOUS: %.o *.o file.o will actually work

On Tue, Oct 8, 2024 at 11:16 PM Dan Jacobson wrote: > > Manual says: > >You can list the target pattern of an implicit rule (such as '%.o') >as a prerequisite of the special target '.PRECIOUS' to preserve >intermediate files made by implicit rules whose target patterns match >that

Re: makeerror-4.4-x86_64-pc-linux-gnu-xc2u.tar.gz

On Tue, 2024-05-14 at 06:33 +, linha...@163.com wrote: > os: wsl centos7 > > make step: > > wget https://ftp.gnu.org/pub/gnu/make/make-4.4.1.tar.gz > tar zxf make-4.4.1.tar.gz > cd make-4.4.1 > ./configure --prefix=/usr > type make > make check The failure is that instead of proceeding norma

Re: set $*, $@ upon reaching the colon

On Thu, 2024-06-13 at 07:55 +0800, Dan Jacobson wrote: > %.all.kmz: $(addsuffix .kml, $(addsuffix .$*.lines,0 1) $(addsuffix > .$*.labels,0 1)) > ls $* > $ make nnn.all.kmz > > Here, upon reaching the colon, the make program already has all the > information it needs to set $* to "nnn". Th

Re: The man and Info pages say different things about make -p

On Tue, 2024-06-25 at 05:49 +0800, Dan Jacobson wrote: > The man and Info pages say different things: > To print the data base without trying to remake any files, use 'make > -qp'. > > To print the data base without trying to remake any files, use make - > p -f/dev/null. This was already fixed a

Re: fixes for unlikely pointer overflow, buffer truncation

On 8/5/24, Paul Eggert wrote: If snprintf (buf, sizeof buf, ...) returns an integer I such that (0 <= I < sizeof buf) then the snprintf worked, the contents of buf[0] through buf[I] are valid, and buf[I] == '\0'. Otherwise snprintf didn't work and buf's contents are indeterminate. In practic

Re: fixes for unlikely pointer overflow, buffer truncation

On Mon, 2024-08-05 at 14:26 -0700, Paul Eggert wrote: > Good memory! Just old :p :) > GNU Make should either (a) not worry about porting to SunOS 4, (b) > rewrite ar_member_touch to not use snprintf, or (c) import Gnulib's > snprintf module which unfortunately is pretty heavyweight. I vote for

Re: fixes for unlikely pointer overflow, buffer truncation

> From: Martin Dorey > CC: "bug-make@gnu.org" > Date: Mon, 5 Aug 2024 23:13:47 + > > "Beginning with the UCRT in Visual Studio 2015 and Windows 10, snprintf is no > longer identical to _snprintf. The snprintf behavior is now C99 standard > conformant. The difference is that if you run out

Re: fixes for unlikely pointer overflow, buffer truncation

On 2024-08-05 16:13, Martin Dorey wrote: "Beginning with the UCRT in Visual Studio 2015 and Windows 10, snprintf is no longer identical to _snprintf. The snprintf behavior is now C99 standard conformant. The difference is that if you run out of buffer, snprintf null-terminates the end of the b

Re: fixes for unlikely pointer overflow, buffer truncation

>> all systems providing correct >> sprintf() return values these days?  ISTR that some C runtime >> implementations didn't correctly return the formatted length. > 7th Edition Unix sprintf returned char * Perhaps the buffer is always big enough here. If not, though, then the more recent diffe

Re: fixes for unlikely pointer overflow, buffer truncation

On 2024-08-05 12:22, Paul Smith wrote: On Mon, 2024-08-05 at 01:59 -0700, Paul Eggert wrote: The first three patches are minor cleanups. Is it the case that we can rely on all systems providing correct sprintf() return values these days? ISTR that some C runtime implementations didn't correct

Re: fixes for unlikely pointer overflow, buffer truncation

On Mon, 2024-08-05 at 01:59 -0700, Paul Eggert wrote: > The first three patches are minor cleanups. Is it the case that we can rely on all systems providing correct sprintf() return values these days? ISTR that some C runtime implementations didn't correctly return the formatted length. But mayb

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

On Fri, 21 Jun 2024 11:36:16 -0400 Dmitry Goncharov wrote: > 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 lo

Re: inconsistent use of CFLAGS in the GNU make manual

On 2024-07-08 11:44:45 -0400, Paul Smith wrote: > On Mon, 2024-07-08 at 17:17 +0200, Vincent Lefevre wrote: > > foo : $(objects) > >     cc -o foo $(CFLAGS) $(objects) > > > > This is misleading because $(CFLAGS) is not used in the implicit > > rule. > > I'm not sure I see the issue here (and

Re: inconsistent use of CFLAGS in the GNU make manual

On Mon, 2024-07-08 at 17:17 +0200, Vincent Lefevre wrote: > foo : $(objects) >     cc -o foo $(CFLAGS) $(objects) > > This is misleading because $(CFLAGS) is not used in the implicit > rule. I'm not sure I see the issue here (and with the example for .EXTRA_PREREQS): this is not an implicit r

Re: Unable to make drogon-assist

Thanks guys I now have a good starting point. Turns out the code has other errors I have to reach out to the maintainers about. On Tue, Jul 2, 2024, 6:06 AM Paul Smith wrote: > On Mon, 2024-07-01 at 14:31 -0700, Albaro Pereyra wrote: > > /home/albaro/drogon-assist/drogon/assist/passwdhash.cpp:2

Re: Unable to make drogon-assist

On Mon, 2024-07-01 at 14:31 -0700, Albaro Pereyra wrote: > /home/albaro/drogon-assist/drogon/assist/passwdhash.cpp:20:15: error: > ‘string_view’ does not name a type >    20 |         const string_view alphabet = > "1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"; >       |        

Re: Unable to make drogon-assist

Albaro Pereyra (01 July 2024 23:31) quoted: > /home/albaro/drogon-assist/drogon/assist/passwdhash.cpp: In function > ‘std::string drassist::secureRandomString(size_t)’: > /home/albaro/drogon-assist/drogon/assist/passwdhash.cpp:20:15: error: > ‘string_view’ does not name a type >20 | c

  1   2   3   4   5   6   7   8   9   10   >