RE: [bug #62654] Add z/OS support

2022-07-03 Thread Paul Smith
I prefer to do the review via email rather than in the Savannah bug tracker which has pretty annoying markup. I would appreciate a somewhat comprehensive commit message or ChangeLog for this set of patches, at least explaining some of the less obvious modifications. > +set -x > +if [ !

Re: Goodbye to GNU make's "build.sh" ... ?

2022-06-27 Thread Paul Smith
On Sun, 2022-06-26 at 22:00 -0400, Dmitry Goncharov wrote: > What was the original driving force to introduce build.sh? As mentioned, the goal of "build.sh" is to allow systems without an already-existing make program to bootstrap themselves, by providing a way to build GNU make without using

Re: Goodbye to GNU make's "build.sh" ... ?

2022-06-26 Thread Paul Smith
On Sun, 2022-06-26 at 16:57 -0400, Dmitry Goncharov wrote: > Have you considered to to avoid glob from gnulib? Make has its one > impl of glob which it uses on certain systems. > We could use this impl and maintain it on all systems. While the original issue came up WRT glob, in actuality the

Re: Goodbye to GNU make's "build.sh" ... ?

2022-06-26 Thread Paul Smith
On Sun, 2022-06-26 at 17:39 +0300, Eli Zaretskii wrote: > > The problem is that the process for "make-less" systems in the past > > has been: run configure, then run build.sh.  But we won't be able > > to use the environment created by configure in this "new" build.sh, > > because it works in

Re: Goodbye to GNU make's "build.sh" ... ?

2022-06-26 Thread Paul Smith
On Sun, 2022-06-26 at 07:34 +0100, Sven C. Dack wrote: > 3. Allow to build a minimal Make executable, which provides basic and > traditional Make functionality and does not rely on gnulib, and then > use it as a bootstrap. It's certainly a possibility. But there is already so much ifdef etc. in

Re: Goodbye to GNU make's "build.sh" ... ?

2022-06-26 Thread Paul Smith
On Sun, 2022-06-26 at 08:41 +0300, Eli Zaretskii wrote: > It is sad that Gnulib maintainers aren't prepared to cater to a GNU > project, and an important one such as Make.  These are special > requirements that only a handful of GNU project could ever have, and > for good reasons, so supporting

Re: Goodbye to GNU make's "build.sh" ... ?

2022-06-26 Thread Paul Smith
On Sun, 2022-06-26 at 02:14 +0200, Henrik Carlqvist wrote: > Would  this "old version of make" have to be GNU make? It would need to be some version of make that is supported by automake. As far as I'm aware, automake-generated makefiles are currently intended to run with any POSIX-compliant

Goodbye to GNU make's "build.sh" ... ?

2022-06-25 Thread Paul Smith
I'm trying to decide what the future is for GNU make's "build.sh" bootstrapping script. As you may recall, this script is provided to allow GNU make to build on systems which don't already have an instance of make installed. Its goal is to build the first make binary, without of course all the

Re: Crash in 'find_and_set_default_shell()'

2022-06-19 Thread Paul Smith
On Sun, 2022-06-19 at 08:47 +0300, Eli Zaretskii wrote: > > I do have a memory that some versions of Visual Studio, up until > > relatively recently, have non-standard implementations of > > snprintf() > > but hopefully it's standard enough to manage this. > > If we now rely on ANSI-standard

Re: Crash in 'find_and_set_default_shell()'

2022-06-18 Thread Paul Smith
On Wed, 2022-05-11 at 08:00 +0200, Gisle Vanem wrote: > The crash and wild call-stack seems to be caused > by an overflow to 'sprintf(sh_path, ..)'. But replacing > with 'snprintf()' works w/o any crash: I applied changes based on this: some didn't need sprintf() at all; the rest I used

Re: Potential Bug: `.PHONY` targets and order-only prerequisites

2022-05-21 Thread Paul Smith
On Sat, 2022-05-21 at 14:34 -0400, Dmitry Goncharov wrote: > On Sat, May 21, 2022 at 12:25 PM Paul Smith wrote: > > Maybe what you're saying is that make should throw an error or > > warning if you try to add an order-only prerequisite to a phony > > target, telling

Re: floating point exception 8 when running make

2022-05-21 Thread Paul Smith
On Sat, 2022-05-21 at 12:17 -0700, Valery Tolkov wrote: > Exact target file doesn't matter, all files give the same error. If I > do a clean build without any existing targets, it works. But second > time it fails again. > > > ... > > Must remake target `bin/dbg/clr/clr.o'. > > clang++ --config

Re: Potential Bug: `.PHONY` targets and order-only prerequisites

2022-05-21 Thread Paul Smith
On Sat, 2022-05-21 at 19:06 +0200, Alejandro Colomar wrote: > By "once all children are complete" you are implying the "existence" > of the children (which make(1) doesn't really check, but one can > think of it as if it did). Perhaps that's the confusion. Make doesn't care about files at all

Re: Potential Bug: `.PHONY` targets and order-only prerequisites

2022-05-21 Thread Paul Smith
On Wed, 2022-05-18 at 14:36 -0700, Jacob Kopczynski wrote: > The thing that the docs refer to as "impose order" is not a single > thing, but two. I would characterize a normal prerequisite as doing > three things rather than two: > - update-marking: cause a target to be marked out of date if the >

Re: Potential Bug: `.PHONY` targets and order-only prerequisites

2022-05-18 Thread Paul Smith
On Wed, 2022-05-18 at 10:22 -0700, Jacob Kopczynski wrote: > I believe I understand. The name "order-only" is highly misleading > and should be changed - it does considerably more than "only" > "order"; the only thing it does not do is check the timestamp. As described in the docs there are only

Re: Potential Bug: `.PHONY` targets and order-only prerequisites

2022-05-17 Thread Paul Smith
On Tue, 2022-05-17 at 22:32 +, Martin Dorey wrote: > >  all your targets are .PHONY, and thus are always rebuilt anyway > > If you "make down", the rule for "down-clean" doesn't run.  They're > only rebuilt if something causes them to be considered. > > >  order-only prerequisites are

Re: Potential Bug: `.PHONY` targets and order-only prerequisites

2022-05-17 Thread Paul Smith
On Tue, 2022-05-17 at 17:20 -0400, Paul Smith wrote: > this says two things: first, that b and c will both be rebuilt (if > necessary) before a's recipe is started, I guess I should be more clear about the "(if necessary)". What I mean is the same as if you had run "make b&

Re: Potential Bug: `.PHONY` targets and order-only prerequisites

2022-05-17 Thread Paul Smith
On Tue, 2022-05-17 at 14:00 -0700, Jacob Kopczynski wrote: > I'm unsure whether this is a bug or just undocumented, but I found a > confusing interaction in a simple Makefile: You are misreading the documentation. I will quote: > A normal prerequisite makes two statements: first, it imposes an

Re: Archive Members as Targets

2022-05-11 Thread Paul Smith
On Tue, 2022-05-10 at 22:45 +0200, Michael Lehn wrote: > But not on the Linux boxes there make always rebuild everything. On > all machines I am using GNU Make. This is because whatever GNU/Linux distribution is being used, has configured their binutils so that ar is in "deterministic mode" by

Re: Crash in 'find_and_set_default_shell()'

2022-05-10 Thread Paul Smith
On Tue, 2022-05-10 at 15:03 +0200, Gisle Vanem wrote: > SHELL := env "PATH=$(PATH)" /bin/bash Well, I dunno. The problem is that at some point you have to choose which command to use to invoke something. The SHELL variable is intended to contain a shell program that make will exec(). Here

Re: [PATCH v1 2/2] misc: Replace strcmp with memcmp when it obviously works

2022-04-24 Thread Paul Smith
I applied both of these patches, thanks!

Re: Wooden toy

2022-04-20 Thread Paul Smith
On Wed, 2022-04-20 at 21:36 +0800, Eliza Tan via Bug reports and discussion for GNU make wrote: > How are you ? Sorry, this got approved in moderation when it shouldn't have been.

Re: A translate mistake in Gnu make 4.3

2022-04-01 Thread Paul Smith
On Fri, 2022-04-01 at 16:06 +0800, calvin wrote: > "Flags" should be translated to "标志" not "旗标" in Chinese Thanks for your interest!  All GNU make translations are handled through The Translation Project: https://translationproject.org/html/welcome.html Please report any issues to the GNU

Re: GNU Make bug report: broken dry-run functionality with sub-make invocations

2022-03-21 Thread Paul Smith
(We generally prefer to use inline replies on the GNU lists, rather than top-posted replies, thanks) On Mon, 2022-03-21 at 13:22 +, Ambrus Sumegi wrote: > If the invocation is a function, i.e., `$(make,"external_target") | > tee logs/external_task.log` then Make knows exactly where the call

Re: GNU Make bug report: broken dry-run functionality with sub-make invocations

2022-03-21 Thread Paul Smith
On Mon, 2022-03-21 at 09:34 +, Ambrus Sumegi wrote: > For the record, I’ve thought of a sort-of-solution to the “would you > have Make parse the shell command” question over the weekend. If the > sub-make was called through a function rather than a variable, the > whole issue could be a lot

Re: [PATCH] Author: Nenghe Wang <545934...@qq.com>

2022-03-20 Thread Paul Smith
Thank you for the patch. It's most helpful if you can provide an example of the warning you're trying to address, when you send the patch. Cheers! On Sat, 2022-03-19 at 19:42 +0800, boxues...@126.com wrote: > From: wnh <545934...@qq.com> > > Adjust header file order in

Re: Bug report made anonymously should be assigned to my username on Savannah for receiving updates on it

2022-03-18 Thread Paul Smith
On Fri, 2022-03-18 at 21:12 +, Lahfa Samy wrote: > I've reported this bug anonymously : > https://savannah.gnu.org/bugs/index.php?62200 and would like to > receive updates/comments on it by mail on my Savannah account, I > don't know if the bug report could be assigned to me or the "posted >

Re: GNU Make bug report: broken dry-run functionality with sub-make invocations

2022-03-18 Thread Paul Smith
On Fri, 2022-03-18 at 17:48 +, Martin Dorey wrote: > Maybe putting it in the form of a patch on the latest git source will > help it over the finish line: I'm OK with adding some short text about this into the man page. As David mentions it may be important enough to do that since command

Re: GNU Make bug report: broken dry-run functionality with sub-make invocations

2022-03-17 Thread Paul Smith
On Thu, 2022-03-17 at 18:27 +, Martin Dorey wrote: > That coped with -nj --no-print-directory on the one version of Make > that I tested it with, but I don't know how portable that would > prove. Modern versions of make guarantee a canonical format of MAKEFLAGS such that you can parse them

Re: [PATCH] Fix src/function.c build failure on gcc-12.

2022-02-21 Thread Paul Smith
On Mon, 2022-02-21 at 08:59 +, Edward Welbourne wrote: > and that's assuming a 32-bit int; the signed range is from - > 2,147,483,647 to 2,147,483,648.  However, may I suggest the following > (which I know included in the GPL'd cfengine sources at some point): This computation is already

Re: Make losing jobserver tokens on Windows

2022-02-21 Thread Paul Smith
On Mon, 2022-02-21 at 15:56 +0100, Magnus Ihse Bursie wrote: > I'm trying to built it from source right now (and it does not seem > complicated), but even so, an official binary makes sure I'm not > introducing any issues from my local build environment. There is no such thing as an "official

Re: [PATCH] Fix src/function.c build failure on gcc-12.

2022-02-21 Thread Paul Smith
On Mon, 2022-02-21 at 08:59 +, Edward Welbourne wrote: > and that's assuming a 32-bit int; the signed range is from - > 2,147,483,647 to 2,147,483,648.  However, may I suggest the following > (which I know included in the GPL'd cfengine sources at some point): This computation is already

Re: GNU Make app and right text output with echo

2022-02-19 Thread Paul Smith
On Sat, 2022-02-19 at 17:40 +0200, Eli Zaretskii wrote: > > From: > > Date: Sat, 19 Feb 2022 14:25:47 +0100 (CET) > > > > Problem is wisible on follow example of file Makefile.win: > > > > all : > >   echo $(pkg-config --libs glib-2.0) > > This is wrong, you want > > all : >

Re: Make losing jobserver tokens on Windows

2022-02-18 Thread Paul Smith
On Fri, 2022-02-18 at 10:18 +0100, Magnus Ihse Bursie wrote: > make[2]: INTERNAL: Exiting with 1 jobserver tokens available; should > be 24! > > This effectively turns the highly parallelized builds into > single-threaded builds, and is absolutely detrimental for > performance. :-( On the flip

Re: oddball messages on FreeBSD that cause make to fail the testsuite

2022-02-14 Thread Paul Smith
On Mon, 2022-02-14 at 18:54 -0500, Dennis Clarke wrote: > variable 'plugin_is_GPL_compatible' [-Wmissing-variable-declarations] This is happening because you're adding extra compile-time options to the standard GNU make build, and those options are getting passed through to the test suite. Most

Re: Errors in man pages of make

2022-02-07 Thread Paul Smith
On Mon, 2022-02-07 at 18:18 +0100, Helge Kreutzmann wrote: > > This channel is fine, but please always do include the release of > > GNU make that you're looking at when you submit changes (run "make > > --version"). > > This I don't know. I receive the man pages from Fedora, SUSE, > Archlinux,

Re: Errors in man pages of make

2022-02-06 Thread Paul Smith
On Sat, 2022-02-05 at 11:24 +0100, Helge Kreutzmann wrote: > I'm now reporting the errors for your project. If future reports > should use another channel, please let me know. This channel is fine, but please always do include the release of GNU make that you're looking at when you submit changes

Re: Bug in $(shell ...) I can't understand

2022-02-06 Thread Paul Smith
as printing the _stdout_ of the invoked shell to make's stderr, if the shell exited with code 127 (see the source I mentioned previously). > On Sun, Feb 6, 2022 at 4:48 PM Paul Smith wrote: > > I decided this was a bug and changed the behavior for the next > > release. > > Wh

Re: Bug in $(shell ...) I can't understand

2022-02-06 Thread Paul Smith
On Sun, 2022-02-06 at 15:21 -0500, Paul Smith wrote: > I'm not sure this is correct.  I will need to think about it. I decided this was a bug and changed the behavior for the next release.

Re: Bug in $(shell ...) I can't understand

2022-02-06 Thread Paul Smith
On Sun, 2022-02-06 at 20:18 +0300, Dmitry V. Levin wrote: > 4175643 write(2, "/bin/sh: bad-program: command no"..., > 40) = 40 > 4175640 <... read resumed>"/bin/sh: bad-program: command no"..., 200) = 40 > 4175640 read(5,  > 4175643 +++ exited with 127 +++ > 4175640 <... read resumed>"", 160)

Bug in $(shell ...) I can't understand

2022-02-06 Thread Paul Smith
OK, someone posted a question to SO and that led me to an hour or more of banging my head against a wall trying to understand what's happening... and I can't. The problem is that the user would like to invoke $(shell ...) and capture errors, even errors that the program being run doesn't exist.

Re: [PATCH] RFC: add --shuffle[=seed] argument support

2022-02-05 Thread Paul Smith
Nice work! On Sat, 2022-02-05 at 22:04 +, Sergei Trofimovich wrote: > Some high level TODOs: For this amount of change it's likely that you'll need to provide copyright assignment paperwork. Let me know if you'd like more details about this. > - No documentation for the optin yet. This

Re: Idea of triggering bugs in users' Makefiles

2022-02-04 Thread Paul Smith
On Fri, 2022-02-04 at 09:13 +, Sergei Trofimovich wrote: > 1. Enable parallel builds by GNU make by default > > 2. Do not run dependencies in deterministic order by default: GNU make (unlike Ninja) is bound by the POSIX standard in terms of its behaviors. The POSIX standard makes very clear

Re: [BUG] --warn-undefined-variable is not triggered in prerequisites

2022-01-28 Thread Paul Smith
On Fri, 2022-01-28 at 01:09 +0100, Alejandro Colomar (man-pages) wrote: > I'd like make to warn about this. It took me a while to debug > a Makefile bug, which I thought was not happening, since make should > have warned me. Isn't this supposed to trigger the warning? In previous versions of

Re: Paths above current/working directory don't work with suffix rules

2022-01-24 Thread Paul Smith
On Mon, 2022-01-24 at 21:27 +0100, Adam Tuja wrote: > SRCS = a.c b.c ../c-1up.c > OBJS = $(SRCS:.c=.o) > > .c.o: > $(CC) $(CFLAGS) -c -o $@ $< > > $(PROG): $(OBJS) > > Now, when I understand it, it works. It's not the same thing as > objects are placed beside source files but step

Re: Paths above current/working directory don't work with suffix rules

2022-01-24 Thread Paul Smith
On Mon, 2022-01-24 at 19:09 +0100, Adam Tuja wrote: > It doesn't matter how with many levels above current directory the > path has (../ ../../ ...), it's still the same. Suffix rules are very limited: this is why pattern rules were invented. As long as you're happy with creating the object file

Re: Expansion of $(eval..)

2022-01-22 Thread Paul Smith
On Sat, 2022-01-22 at 13:59 +0100, Gisle Vanem wrote: >define add_c_src> > VPATH += $(1) > C_SRC += $(addprefix $(1)/, $(2)) > $(info Number of 'C_SRC': $(words $(C_SRC))) >endef > >$(eval $(call add_c_src, frmts/ceos, ceosopen.c)) >$(eval $(call add_c_src,

Re: $(info xxx) output interleaved with other $(info) output

2022-01-19 Thread Paul Smith
examined this method and in fact, it's not possible for it to be called with anything other than exactly one argument so all the mess around recombining multiple arguments is useless. I rewrote this function and applied this change: Author: Paul Smith Date: 2022-01-19 15:49:19 -0800 Avo

Re: Invalid use of const pointer?

2022-01-19 Thread Paul Smith
On Tue, 2022-01-18 at 10:56 -0500, Joe Filion wrote: > I could recommend changing line 557 to something like: > > const char * cp = strchr (nptr, ‘%’); Good idea, thanks. I cleaned up this section of code.

Re: Linux /proc/loadavg

2022-01-19 Thread Paul Smith
On Sat, 2022-01-15 at 10:29 +, Sven C. Dack wrote: > I have recently been looking into this again, because of a new > feature I am currently testing, and so far can only repeat what I > have already said in the past. The /proc/loadavg file under Linux > with a vanilla kernel is behaving as

Re: [PATCH] Fix nonzero detection in integer parsing

2022-01-17 Thread Paul Smith
On Thu, 2022-01-13 at 23:31 +0100, Jouke Witteveen wrote: > I would like to draw attention to this patch again, since without > it the intcmp function is misbehaving. Thanks for reminding me: somehow the original got deleted from my inbox without being applied. I've now applied it to my Git repo

Re: Invalid use of const pointer?

2022-01-17 Thread Paul Smith
On Sun, 2022-01-09 at 20:02 -0500, Joe Filion wrote: > If interested, I found another similar construct in another area of > the code. Don’t worry, this appears to be the last one. > > On line 557 of implicit.c: > p = strchr (nptr, '%'); > nptr is a const pointer, but p is used

Re: .SILENT: clobbered by .SILENT: with_target

2022-01-17 Thread Paul Smith
On Wed, 2022-01-12 at 14:22 -0900, Britton Kerin wrote: > > You can see that this example mimics your .silent example. > > Your makefile provided a prerequisite to .SILENT. Make then knows > > that .SILENT has a prerequisite. > > I agree that it's consistent syntax, but semantically it's bad.

Re: Invalid use of const pointer?

2022-01-11 Thread Paul Smith
On Tue, 2022-01-11 at 10:57 +, Edward Welbourne wrote: > Indeed. The compiler is allowed to place a string literal in read- > only memory, where modifying it (even if you do "put it back the way > it was" later) is an access violation. Passing such a const char * > to your function would

Re: Invalid use of const pointer?

2022-01-09 Thread Paul Smith
On Sun, 2022-01-09 at 11:06 +0100, Henrik Carlqvist wrote: > On Sat, 08 Jan 2022 17:29:33 -0500 Paul Smith wrote: > > It turns out to be innocuous because none of the callers care that > > the value of the input string is modified if we return a different > > string,

Re: Invalid use of const pointer?

2022-01-08 Thread Paul Smith
On Sat, 2022-01-08 at 22:34 +0100, Henrik Carlqvist wrote: > But what about the case marked with <--X above? To me it seems as if > the function returns after having modified const char *name bu using > userend. You're right, that's wrong. It turns out to be innocuous because none of the callers

Re: Segafult while running make(1) from /lib/init/rc with -j

2022-01-08 Thread Paul Smith
On Sat, 2022-01-08 at 21:37 +0100, Alejandro Colomar (man-pages) wrote: > Hi Dmitry, > On 1/7/22 17:48, Dmitry Goncharov wrote: > > On Thu, Jan 6, 2022 at 2:13 PM Alejandro Colomar (man-pages) > > wrote: > > >I could try to write a simpler Makefile > > That would be good. We need to be able

Re: Invalid use of const pointer?

2022-01-08 Thread Paul Smith
On Sat, 2022-01-08 at 19:47 +0100, Henrik Carlqvist wrote: > On Sat, 08 Jan 2022 10:37:17 -0500 > Paul Smith wrote: > > The const-correct way to write this code would be to allocate a new > > string and modify that > > Another correct way to do this would be to not decl

Re: Invalid use of const pointer?

2022-01-08 Thread Paul Smith
On Fri, 2022-01-07 at 18:28 -0500, Joe Filion wrote: > Line 3094 of read.c is: > > char *userend = strchr (name + 1, '/'); > > The name parameter is a const pointer, so the overloaded version of > strchr that takes a const pointer as the first parameter should also > return a const pointer.

Re: Oddness with intermediate files / .INTERMEDIATE

2021-12-30 Thread Paul Smith
On Wed, 2021-12-29 at 18:04 -0500, Paul Smith wrote: > This is just not a good idea anyway, and now that we have the > is_explicit value in the file structure we don't need it so I removed > that code. Unfortunately is_explicit is not correctly preserved in > pattern_search(

Oddness with intermediate files / .INTERMEDIATE

2021-12-29 Thread Paul Smith
While looking through some old bugs in Savannah and trying to reproduce them I ran across this change in behavior between GNU make 4.3 and current Git master HEAD: $ cat Makefile 1.all: 1.q ; touch $@ %.q: 1.r ; touch $@ %.r: ; touch $@ Note here, 1.r is mentioned explicitly in the

Re: escaped newline in macro expansion in command line

2021-12-29 Thread Paul Smith
On Fri, 2021-12-24 at 23:30 +, Humm wrote: > (woops, sorry for replying off-list first; mutt doesn’t like me) > > Quoth Paul Smith: > > In your example the backslash is part of a variable expansion: it's > > INSIDE the variable expansion so it will be handled by make as

Re: escaped newline in macro expansion in command line

2021-12-24 Thread Paul Smith
On Fri, 2021-12-24 at 10:45 +, Humm wrote: > Consider the Makefile: > > .POSIX: > M = word > all: > echo ${M:word=a\ > b} > > I believe, as the escaped newline is in a command line, the expected > behavior is to let the macro expand to

Re: make -j does not work on RedHat7.7 VM

2021-12-23 Thread Paul Smith
On Thu, 2021-12-23 at 12:49 +, Zhu, Mason wrote: > In GNU Make 3.82, it seems that -j option will be finally added if > Make determines my VM has the parallel build capability. It has never been the case that any version of GNU make has automatically enabled parallel builds by itself. It's

Re: [PATCH] doc: note that $(wildcard) is implemented in terms of glob(3)

2021-12-20 Thread Paul Smith
Ævar Arnfjörð Bjarmason writes: > Aside: I found it difficult to figure out how to submit patches to > this project. The Savannah page suggests the bug tracker, but as af > writing (and I'm logged in, as "avar") that link appears greyed out > in the web interface, and has a . I added a note to

Re: Compilation error with GCC

2021-12-19 Thread Paul Smith
On Sun, 2021-12-19 at 20:04 +0100, Jouke Witteveen wrote: > The patches "file #52422" and "file #52428" should resolve your > issues. I pushed these changes to Git.

Re: Confusing message when make starts in current directory

2021-12-15 Thread Paul Smith
On Wed, 2021-12-15 at 17:59 +0100, Andrea Monaco wrote: > In my opinion, those messages should always come with a chdir. Well, make can't know whether the previous make started in the same directory or not, at least not reliably. If you do something like the very common, and POSIX-compatible:

Re: .SECONDEXPANSION problems

2021-12-13 Thread Paul Smith
On Sun, 2021-12-12 at 20:35 -0500, Dmitry Goncharov wrote: > On Sun, Dec 12, 2021 at 2:15 PM Paul Smith wrote: > > Did something happen when it stopped working, like you updated to a > > different version of GNU make? > > i bet this make is built from the current gi

Re: .SECONDEXPANSION problems

2021-12-12 Thread Paul Smith
On Thu, 2021-12-09 at 12:25 +0100, Gisle Vanem wrote: > Since some time the cool '.SECONDEXPANSION' feature has stopped > working for me. Did something happen when it stopped working, like you updated to a different version of GNU make? > In a Makefile, I have many rules to link module .DLLs: >

Re: [PATCH] doc: note that $(wildcard) is implemented in terms of glob(3)

2021-12-05 Thread Paul Smith
On Fri, 2021-12-03 at 22:10 +0100, Ævar Arnfjörð Bjarmason wrote: > Would a patch that's updated to note that, and discusses the behavior > in older versions be acceptable for inclusion? I added a note about this to the docs. Thanks for pointing it out!

Re: [PATCH] doc: note that $(wildcard) is implemented in terms of glob(3)

2021-12-03 Thread Paul Smith
On Fri, 2021-12-03 at 11:08 +0100, Ævar Arnfjörð Bjarmason wrote: > The motivation for this patch is that I've seen code like this in the > wild: > > FILES = $(sort $(wildcard t*.sh)) > > I thought that it would be documented that that sort of thing was > redundant, but I didn't find any

Re: GPL Interpretation on load [Was: [bug #61594] suggest new $(hash ...) function]

2021-12-01 Thread Paul Smith
On Wed, 2021-12-01 at 09:33 -0500, rsbec...@nexbridge.com wrote: > That is understood. Is this an official GNU Make policy because it is > not specified that way in GPL. Has the GNU Make team modified their > copy of the GPL license because it is not indicated as a modified > version? I'm not

Re: [PATCH] Fix type errors in win32.

2021-11-28 Thread Paul Smith
On Mon, 2021-10-25 at 15:32 +0300, Eli Zaretskii wrote: > the default C runtime used by Make doesn't support %llu, at least not > on Windows versions older than Windows 10. Hrm, I just added a new use of sprintf() with %lld into GNU make, to format a long long variable. It worked for me in my

Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison

2021-11-28 Thread Paul Smith
On Sun, 2021-11-28 at 15:49 +0100, Jouke Witteveen wrote: > I fully agree, but was not aware of the robustness of INTSTR_LENGTH. > It felt a bit fragile when I spotted its definition in makeint.h. The C standard defines the largest unsigned long long value as 18446744073709551615, the largest

Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison

2021-11-28 Thread Paul Smith
On Sun, 2021-11-28 at 08:24 +0100, Jouke Witteveen wrote: > On the user side, strcmp could now probably be defined something like > $(and $(intcmp $(words $1),$(words $2)),$(findstring x$1x,x$2x)) I don't think this is equivalent since a putative strcmp would also do greater / less than

Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison

2021-11-28 Thread Paul Smith
On Sun, 2021-11-28 at 14:57 +0100, Jouke Witteveen wrote: > > Since the two arguments are equal, it doesn't matter which of LHS > > or RHS we return. > > They could differ for instance when one of them contains a '+'-sign. > My reason for using LHS is that we already have a string for it. I

Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison

2021-11-28 Thread Paul Smith
On Sun, 2021-11-28 at 08:24 +0100, Jouke Witteveen wrote: > Thanks for sending this message, I would have otherwise prepared and > sent an updated patch series today. My plan was to expand to RHS in > the two-argument case if both values are equal. I assume you also > updated the documentation

Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison

2021-11-27 Thread Paul Smith
On Mon, 2021-11-15 at 20:49 +0100, Jouke Witteveen wrote: > It may be obscure, but how about we implement this as well? Sure, the > two-argument form of $(compare) will be a little inconsistent, but it > may be useful. I applied this three-patch set. I left the argument order as you originally

Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison

2021-11-14 Thread Paul Smith
On Wed, 2021-11-10 at 18:19 +0100, Jouke Witteveen wrote: > On Mon, Nov 8, 2021 at 4:08 PM Paul Smith wrote: > > > On Fri, 2021-07-16 at 14:04 +0200, Jouke Witteveen wrote: > > > $(compare > > > @var{lhs},@var{rhs},@var{lt-part}[,@var{eq-part}[,@var{gt-part}

Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison

2021-11-08 Thread Paul Smith
On Fri, 2021-07-16 at 14:04 +0200, Jouke Witteveen wrote: > +@item $(compare > @var{lhs},@var{rhs},@var{lt-part}[,@var{eq-part}[,@var{gt-part}]]) Let me ask this: would it be better to use a format of: $(compare , , [, [, ]]) Then the rule is, if the values are equal we get the part, if lhs

Re: [bug #61226] A regression prevents generation of missing included dependency files.

2021-10-25 Thread Paul Smith
On Mon, 2021-10-25 at 17:51 -0400, Dmitry Goncharov via Bug reports and discussion for GNU make wrote: > On Monday, October 25, 2021, Alejandro Colomar (man-pages) < > alx.manpa...@gmail.com> wrote: > > Why do I do this? Because, if you remove a file from your tree, an > > old .d file will

Re: -V, --verbose, as opposite of -s, --silent, --quiet

2021-10-25 Thread Paul Smith
On Mon, 2021-10-25 at 22:28 +0200, Alejandro Colomar (man-pages) wrote: > Since I use '--warn-undefined-variables', and also to help > readability to someone who may not know about this usage and may > wonder what does that $(V) mean, I used the following: > > V := > $(V).SILENT: Looks good.

Re: [bug #61226] A regression prevents generation of missing included dependency files.

2021-10-25 Thread Paul Smith
On Mon, 2021-10-25 at 10:11 +, Edward Welbourne wrote: > Dmitry Goncharov (17 October 2021 18:33) wrote: > > i think, make should not print a warning when a .d file is missing. > > make should proceed and create the missing file. However, when .d > > is present, but make cannot include it,

Re: -V, --verbose, as opposite of -s, --silent, --quiet

2021-10-23 Thread Paul Smith
On Sat, 2021-10-23 at 03:01 +0200, Alejandro Colomar (man-pages) wrote: > I'd like a project to use '--silent' by default, to have readable > output, and hide most of the full commands, which would be too > noisy. > > So, ideally, I'd like to have 'MAKEFLAGS += --silent' in the > Makefile.

Re: Make language

2021-10-12 Thread Paul Smith
On Tue, 2021-10-12 at 14:12 +, Bartol Hrg wrote: > I'm really displeased and agitated. I hope that letting us know what you saw helps you feel better!

Re: Compilation error on master branch (Commit c5d4b7b)

2021-10-03 Thread Paul Smith
On Sun, 2021-10-03 at 23:23 +0200, Mohammad Akhlaghi wrote: > I then ran the standard './configure' and 'make' commands to build > it, but the build failed with the attached error messages when > building 'src/guile.c'. These errors appear to be coming from compiling src/read.c, not src/guile.c.

Re: Parallel job instance identifiers?

2021-09-06 Thread Paul Smith
On Fri, 2021-08-13 at 14:14 +0100, Howard Chu via Bug reports and discussion for GNU make wrote: > I'm looking for a way to expose a job ID number to the individual > jobs, in a consecutive range from 1-[number of jobs]. Not just > unique numbers, for that we could just use $$ already. The purpose

Re: Report 3 UBSan integer overflow bugs found by an automatic fuzzer

2021-09-05 Thread Paul Smith
On Wed, 2021-06-30 at 17:34 +, He Jingxuan wrote: > We tested GNU make with an automatic tool (based on the fuzzer AFL). > A number of test cases triggering UBSan integer overflow errors were > generated. We manually checked those test cases and filtered out > benign cases. Finally, we

Re: GNU make man page typo

2021-09-05 Thread Paul Smith
On Thu, 2021-09-02 at 20:37 +, John Marshall wrote: > On 2 Sep 2021, at 06:40, Zach Petch wrote: > > The second paragraph under DESCRIPTION reads, > > > > > To prepare to use make, you must write a file called the makefile > > that describes the relationships among files in your program, and

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

2021-07-26 Thread Paul Smith
On Sun, 2021-07-25 at 17:29 -0700, David Boyce wrote: > It's simple to detect this on a Unix-like host (see sample script > below) and my contention is that this is "plenty portable enough" Ah. Yes, determining if stdout is /dev/null can be done. I was definitely having an off day yesterday and

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

2021-07-25 Thread Paul Smith
On Sun, 2021-07-25 at 16:04 -0400, Dmitry Goncharov wrote: > > It's clear that /dev/null is a special case, however, because the > > order in which data is written to it cannot be detected so what's > > the point in preserving any order? > > Maybe Mike can tell us. Based on the bug report I

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

2021-07-25 Thread Paul Smith
On Sun, 2021-07-25 at 15:25 -0400, Paul Smith wrote: > There's no reason that those two disjoint sets of output need to be > synchronized WITH EACH OTHER to meet the goal of the -O option. Given > the choice between allowing output to go to these two different > locations in

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

2021-07-25 Thread Paul Smith
On Sun, 2021-07-25 at 13:11 -0400, Dmitry Goncharov wrote: > On Sun, Jul 25, 2021 at 10:03 AM Paul Smith wrote: > > Writing to things like /dev/lp0 SHOULD be locked, IMO: you don't > > want multiple concurrent writers to your printers or your terminal! > > The user intenti

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

2021-07-25 Thread Paul Smith
On Sat, 2021-07-24 at 20:35 -0400, Dmitry Goncharov wrote: > On Sat, Jul 24, 2021 at 3:02 PM David Boyce > wrote: > > I can’t think of a file other than /dev/null which would > > appropriately be shared with unrelated processes in a “w” (write) > > condition. > > /dev/zero, /dev/lp0, /dev/lp1,

Re: [bug #60798] Make does not compile with GCC 11.1.0

2021-06-19 Thread Paul Smith
On Sat, 2021-06-19 at 16:23 +0100, Dmitrii Pasechnik wrote: > > I don't think I understand. > > p[] occupies a continuous memory area, starting from p[0], but p[-1] > is not guaranteed by the standard to be accessible for you (well, > unless you control the memory layout by placing p in a struct,

Re: [bug #60798] Make does not compile with GCC 11.1.0

2021-06-19 Thread Paul Smith
On Sat, 2021-06-19 at 15:31 +0100, Dmitrii Pasechnik wrote: > On Fri, Jun 18, 2021 at 12:53:32PM -0400, Paul D. Smith wrote: > > > Follow-up Comment #1, bug #60798 (project make): > > FWIW, this warning is not valid in this situation. The code is > > correct; p will always be pointing into a

Re: shell assignment operator documentation missing 'not'

2021-05-30 Thread Paul Smith
On Tue, 2021-05-25 at 10:33 +, Ronald Hoogenboom wrote: > In the info file documenting the shell assignment operator in section > 3.7 "reading makefiles", there is the phrase: > > "...that variable becomes a simple variable (and will thus be re- > evaluated on each reference)." > > A simple

Re: basename function in 4.3 cygwin

2021-05-21 Thread Paul Smith
On Fri, 2021-05-21 at 08:31 +, Ronald Hoogenboom wrote: > The difference happens when a suffix contains one or more > backslashes. This is sometimes needed to escape special behavior of > meta characters in the shell. The basename function in 3.81 would > return everything up to the last

Re: basename function in 4.3 cygwin

2021-05-21 Thread Paul Smith
On Fri, 2021-05-21 at 08:31 +, Ronald Hoogenboom wrote: > I have noticed a nasty difference in behavior between 4.3 and 3.81 > versions of gnu-make in cygwin. > > I’m not sure if this qualifies as a bug per-se, but it is a nasty > difference in behavior anyway. At least this should be

Re: [bug #60538] Environment variable overrides explicit assignment

2021-05-06 Thread Paul Smith
On Thu, 2021-05-06 at 17:11 +, Martin Dorey wrote: > So MAKEOVERRIDES is exported, though perhaps it doesn't need to be, > but isn't expanded before being exported. Oh duh!! I didn't provide any overrides. You're right, it is exported. OK I guess I'll have to go back and look at the code

  1   2   3   4   5   6   7   8   9   10   >