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

On Fri, 2024-04-19 at 14:38 -0400, Dmitry Goncharov wrote: > 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 o

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

On Fri, 2024-04-19 at 13:15 -0400, Dennis Clarke wrote: > Yep. The calls to alloca() seem to be all over the place in the code > base and I can not figure out why anyone would want a non-portable > and non-standard thing like that but here we are. alloca() has been used in the GNU Make code ever

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

On Fri, 2024-04-19 at 09:54 -0400, Dennis Clarke via Bug reports and discussion for GNU make wrote: > Where does one even begin to discover where something ( everything? ) > went so horribly wrong? The very first thing you should try is re-configuring GNU Make without any special flags (unset

Re: A question about submitting a new source code file

On Sun, 2024-04-07 at 09:30 -0400, Dmitry Goncharov wrote: > Good morning, Paul. > > Thanks for the explanation. > > On Sun, Apr 7, 2024 at 8:08 AM Paul Smith wrote: > > In short, if you create a new file and assign it to the FSF then > > you can still do whate

Re: Please check about the GIT problem.

On Sat, 2024-04-06 at 16:50 +0900, 12zz12 wrote: > I'm not used to it, so I run the translator. It's no different, but > when I used Ubuntu 22 version and put in the installation command to > install the git and executed it, it shows that this happens as > follows. And you don't have to cover the

Re: A question about submitting a new source code file

On Wed, 2024-04-03 at 09:33 -0400, Dmitry Goncharov wrote: > 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

Re: Pattern rules without recipe

On Fri, 2023-06-09 at 09:39 +0200, Frank Heckenbach wrote: > Another thing that surprised me which I assume is working as > designed, but I think should be spelled out clearer in the manual: I added a paragraph about this to the main page describing pattern rules. Thanks for the note! -- Paul

Re: [PATCH] Fix jobserver does not work on OS/2

On Wed, 2023-12-13 at 20:05 +0900, KO Myung-Hun wrote: > mkfifo() on OS/2 is a dummy, even it returns a wrong value on error. > > Do not use it on OS/2. I applied this change, thanks! -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org

Re: [PATCH] Fix integer overflow test in parse_int

On Sun, 2024-01-07 at 16:09 -0800, Paul Eggert wrote: > * src/arscan.c (parse_int): Use intprops.h macros rather than trying > to detect integer overflow by hand, and doing it incorrectly. > Here is an example of why the old code was incorrect. > If val == 3689348814741910323, base == 10, *ptr ==

Re: Issue with 'src/variable.c'

On Wed, 2024-02-07 at 13:35 +0100, Gisle Vanem wrote: > Since the commit:   > https://git.savannah.gnu.org/cgit/make.git/commit/src/variable.c?id=ec348f51d0240ebc64d11c77c461e89c4a8dfed7 > > src/variable.c doesn't compile: >    variable.c(1642): error C2065: 'specificity': undeclared > identifier

Re: confusing language in manual re GNUMAKEFLAGS

On Tue, 2024-03-05 at 08:54 -0500, DSB wrote: > I think this little nit should be cleared up. In one place the manual > says: > > ... after parsing GNUMAKEFLAGS GNU make sets this variable to the > empty string ... > > But in another place it says: > > GNU make never sets this variable itself.

Re: suggestion regarding names of temp files

On Mon, 2024-03-18 at 13:04 -0400, DSB wrote: > Minor suggestion: In 9.7 Temporary Files the manual says "These files > must not be disturbed while make is running" but it doesn't say what > "these files" look like. Assuming the names have some pattern, would > it make sense to be more specific

Re: TESTs fail features/output-sync and features/parallelism on Linux 4.4.194 armv7l

On Tue, 2024-02-27 at 03:22 -0500, Dennis Clarke via Bug reports and discussion for GNU make wrote: > *** Testing FAILED!  Details: > makeerror-4.4.1-armv7l-unknown-linux-gnueabihf-izkr.tar.gz > *** Please report to Apologies for the delay in replying. When filing a bug report for failed

Re: Conditional append operator (was: Re: New conditional assignment facility)

On Sun, 2024-02-18 at 22:23 +0100, Jouke Witteveen wrote: > On Sun, Feb 4, 2024 at 12:05 AM Paul Smith wrote: > > > I feel these proposals are > 1) not obvious in how they work, regardless of how they work, and > 2) largely possible without new syntax. > > The

Re: Issue with 'src/variable.c'

On Wed, 2024-02-07 at 13:35 +0100, Gisle Vanem wrote: > src/variable.c doesn't compile: >    variable.c(1642): error C2065: 'specificity': undeclared > identifier >    variable.c(1658): error C2065: 'specificity': undeclared > identifier Thanks for this report. It's helpful to include

Re: Conditional append operator (was: Re: New conditional assignment facility)

On Sat, 2024-02-03 at 17:45 -0500, Paul Smith wrote: > Here's how I think the "append changes the type of the variable" > option works: I should have been more clear on my nomenclature. In my examples the column on the right is meant to describe what make has in its memory for

Conditional append operator (was: Re: New conditional assignment facility)

On Mon, 2024-01-29 at 09:52 +, Edward Welbourne wrote: > Perhaps it would be useful to enumerate the other types of assignment This seems useful.  There are two options: the "append changes the type of the variable" option, and the "append doesn't change the type of the variable" option.

Re: Git repo outage

On Tue, 2024-01-30 at 01:13 -0700, Bob Proulx wrote: > Please make a bookmark of this URL to get out-of-band status of > system problems. > >     https://hostux.social/@fsfstatus If you have a mastodon account you can follow that account as well if you prefer. Bob, note that the last update (7h

Re: Handling of MAKEFLAGS

On Thu, 2024-01-11 at 00:37 -0500, Dmitry Goncharov wrote: > You are designing a new feature, aren't you? Specifically, the > ability to unset -e. If really needed, a makefile can reset -e on > the command line for submake and have submake do the work. > Alternatively, it is possible to

Re: New append operators (was: Re: New conditional assignment facility)

On Sun, 2024-01-28 at 18:06 -0500, rsbec...@nexbridge.com wrote: > >     FOO +:= bar > > > > can be interpreted as working like this: > > > >     FOO := $(FOO) bar > > > > which is what you and others are arguing for.  Or it can be > > interpreted as working > > like this: > > > >     __FOO :=

New append operators (was: Re: New conditional assignment facility)

On Mon, 2024-01-22 at 21:33 -0500, Dmitry Goncharov wrote: > 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, be

New append operators (was: Re: New conditional assignment facility)

On Sat, 2024-01-27 at 17:45 -0500, rsbec...@nexbridge.com wrote: > My take on it is that +:= (because of the : ) means that you have to > resolve everything at that point. Yes, I understand what you are saying. The question is, is that the right conception? Here's another way to look at it:

Re: make manual feedback

On Mon, 2024-01-22 at 21:16 +, David Apps wrote: > I have some feedback about the document at the following address: Thanks for your feedback. I applied all these changes, or some form of them, except: > > Do not install executables here in this directory > > Perhaps delete "here". > > >

Re: New conditional assignm ent facility

On Sat, 2024-01-27 at 15:52 -0500, rsbec...@nexbridge.com wrote: > > I'm interested in peoples' opinions about which of these two > > implementations they would feel to be more "intuitive" or > > "correct". Also please consider issues of "action at a distance" > > where a variable is assigned in

Re: New conditional assignment facility

On Mon, 2024-01-22 at 08:15 -0500, Paul Smith wrote: > Let's step back and I'll try to think more clearly about this. Sorry for the delay in replying. I can see that I was thinking about this one way but there's another way to look at it that I didn't think of. We are talking only ab

Re: feature requests: $(__FILE__) and $(__LINE__) textual macros

On Sat, 2024-01-27 at 20:45 +0100, Basile Starynkevitch wrote: > NB I might perhaps implement such a feature if (and only if) I don't > have any copyright assigment to find. In my GCC contributing > experience fifteen years ago, that administrative step was really > painful. I am too old to start

Re: feature requests: $(__FILE__) and $(__LINE__) textual macros

On Sat, 2024-01-27 at 20:27 +0100, Basile Starynkevitch wrote: > > It would be great if you could provide examples where these would > > be > > useful, especially examples that are not already covered by the > > output > > of the -p option to GNU Make. > > make -p don't show (unfortunately) the

Re: feature requests: $(__FILE__) and $(__LINE__) textual macros

On Sat, 2024-01-27 at 18:06 +0100, Basile Starynkevitch wrote: > For non-trivial GNUmakefile-s on Linux it would be nice to have a > $(__FILE__) and $(__LINE__) textual macros of GNU make. It would be great if you could provide examples where these would be useful, especially examples that are

Re: New conditional assignment facility

On Sun, 2024-01-21 at 14:22 -0500, Dmitry Goncharov wrote: > Let us clarify the goal of these enhancements? > i assumed that the goal of these enhancements was to allow code like > hello+:=$(world) > create 'hello' as a simple variable, if 'hello' does not exist yet. > > After reading your !=

Re: New conditional assignment facility

On Sat, 2024-01-20 at 22:18 -0500, Dmitry Goncharov wrote: > > Either we could follow the example of "+=" and say that the assignment > > type in "+:=" only takes effect if the variable doesn't already have a > > type but if it does that type is preserved, so in the above example FOO > > would

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

On Sun, 2024-01-21 at 12:00 +0800, Haoxin Tu wrote: > May I know if you are planning to propose a fix for it? I checked the > implementations of other `make` versions a bit further, and as far as > I can tell, the issue exists from the older make-4.0.90 (2014-9-30) > to the newest version of make

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

On Sat, 2024-01-20 at 23:37 +0800, Haoxin Tu wrote: > But I don't understand why the second invocation of `xrealloc` can > not return zero, I apologize for any imprecise information I provided > in the previous emails. Because of what I said in my original reply: > the entire point of xrealloc

Re: Re: Segmentation Fault on Exported Resursively Expanded Variable

On Tue, 2024-01-16 at 06:59 +, MIAOW Miao wrote: > (gdb) bt > #0  recursively_expand_for_file (v=v@entry=0xad5740, > file=file@entry=0x0) at src/expand.c:119 > ... > #20 0x0041acec in main (argc=, argv= out>, envp=) at src/main.c:2918 This is not as helpful because you've elided the

Re: Segmentation Fault on Exported Resursively Expanded Variable

On Mon, 2024-01-15 at 11:21 +, MIAOW Miao wrote: > I found name of exported resursively expanded variable with $(shell > ...) cannot be too long in gnu make version >= 4.4, otherwise a > segmentation fault is triggled. I'm not sure if variable-name-too- > long is a bug. However, make is >

Re: New conditional assignment facility

On Thu, 2024-01-11 at 14:28 +0100, Alejandro Colomar wrote: > > >   alx@debian:~/tmp$ cat Makefile > > >   var ?= foo > > >   var ?+= bar > > >   $(info $(var)) > > >   alx@debian:~/tmp$ make-9000 > > >   foo bar > > >   make: *** No targets.  Stop. > > >   alx@debian:~/tmp$ make-9000 var=foo > >

Re: New conditional assignment facility

On Thu, 2024-01-11 at 01:44 -0500, Paul Smith wrote: > I've implemented a new capability for conditional assignments (not > pushed yet). > > After these changes, a "?" can precede any type of assignment > operation, not just "=", and make it condition

New conditional assignment facility

I've implemented a new capability for conditional assignments (not pushed yet). After these changes, a "?" can precede any type of assignment operation, not just "=", and make it conditional (that is, it only takes effect if the variable is not already set). So for example, in addition to "?="

Re: Handling of MAKEFLAGS

On Wed, 2024-01-10 at 17:20 -0500, Dmitry Goncharov wrote: > > 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 >

Handling of MAKEFLAGS

Hi Dmitry; I was looking over your patches for dealing with various problems handling command line issues such as not handling -e properly and appending to pattern-specific variables. These are good patches but I'm getting more and more uneasy with the complexity around MAKEFLAGS and I wonder if

Re: How to create symlinks for shared library with soname

On Mon, 2024-01-01 at 04:20 +0800, lijh8 wrote: > libtool creates both symlinks to the real library file.  > But CMake creates one symlink to the real file and another symlink to > the first symlink. > > I'm sticking with manual Makefile but which way should I follow? First, I don't think this

Re: Bug with $(info xxx) in 4.2.1

On Thu, 2023-12-07 at 11:38 -0500, Dmitry Goncharov wrote: > 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. > >

Re: make-4.3 on Linux x86_64 fails features/output-sync test

On Mon, 2023-11-27 at 15:27 -0500, Dennis Clarke via Bug reports and discussion for GNU make wrote: > GNU Make 4.3 Is the failure repeatable? Have you tried it with the latest version of GNU Make? It certainly doesn't fail on my system (which is, obviously, also running x86_64 GNU/Linux). But,

Re: Obs Shader Filter faild to install

On Wed, 2023-11-15 at 08:54 +0100, Jean-François Hicter wrote: > ==> Lancement de build()… > make : option invalide -- 'D' Indeed, "-D" is not a valid option for GNU Make. However, we cannot help more than that because the makefile you are using has disabled all the normal output, which means we

Re: MAKE BUG

On Fri, 2023-10-13 at 13:13 +0530, Nachiketa Gupta wrote: > Hi All, > MAKE version 3.8 > So my question is why does it always print -j independent of -j > value? > is some make.conf file located in our area which is overriding this > variable with -j? > I have also confirmed that with the 4.3

Re: GNU make troubleshooting

On Sun, 2023-09-03 at 02:24 +0200, Alejandro Colomar wrote: > Let's add one more: > > -  Make has problems running the SHELL This is an interesting situation but I don't think it belongs in the GNU make manual. -- Paul D. Smith Find some GNU make tips at: https://www.gnu.org

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

On Thu, 2023-08-31 at 00:08 +0200, Alejandro Colomar wrote: > I ended up using $(foreach ... $(eval ...)).  I didn't know about > $(eval) before reading Paul's troubleshooting guide, and it was mind > opening.  It solves a limitation I thought GNU Make had but really > hadn't.  :) You might want

Re: GNU make troubleshooting

On Tue, 2023-08-29 at 09:44 -0400, David Boyce wrote: > - I find it interesting that there's no mention of -n which seems > like a bog-standard, POSIX-compliant, debugging method. It's also > another way of getting around @. Simplistic but worth mentioning > IMHO. I rarely use -n, personally.

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

On Tue, 2023-08-29 at 11:32 +0200, Alejandro Colomar wrote: > Am I missing something?  Is something like that allowed anyhow? Multiple "%" are allowed, in that they won't throw an error. But, only the first "%" is replaced. The second (and subsequent) "%" are just normal characters, not pattern

Re: GNU make troubleshooting

On Sun, 2023-08-27 at 15:47 +0200, Alejandro Colomar wrote: > In fact, I'm going to define .SILENT always in the Linux man-pages, > since V=1 is just an unnecessary duplicate for --degub=print. > I'll make V=1 only have the effect of redirecting stderr of certain > programs. Just be aware that

Re: GNU make troubleshooting

On Sun, 2023-08-27 at 16:33 +0300, Eli Zaretskii wrote: > That error code 2 means file not found, and -1 means a command was > not found or completely failed to run.  It is easy to show a couple > of examples for each one, we see those every day. That might be true in Windows but it's not the

Re: GNU make troubleshooting

On Sun, 2023-08-27 at 09:26 -0400, Paul Smith wrote: > Yes, that's a good idea to mention .SILENT. Actually I think I will simply recomment using --debug=print instead as that's simpler. -- Paul D. Smith Find some GNU make tips at: https://www.gnu.org h

Re: GNU make troubleshooting

On Sun, 2023-08-27 at 15:21 +0200, Alejandro Colomar wrote: > Maybe mention that removing .SILENT: would be necessary, if > it is defined.  Here's what the Linux man-pages makefiles do. Yes, that's a good idea to mention .SILENT. I really don't want to get into documenting all the different ways

Re: GNU make troubleshooting

On Sun, 2023-08-27 at 08:51 +0300, Eli Zaretskii wrote: > This checklist is very useful, but to make it even more useful, it > lacks two things: > >  . an example of error message that indicates each kind of problem >  . a cross-reference to where the details are There is a menu of links to each

Re: GNU make troubleshooting

I added a new appendix to the GNU make manual for troubleshooting help; I haven't pushed it yet. See below. Comments welcome. I think the outline you provided earlier, Bruno, has the problem that a lot of it isn't really about troubleshooting per se, it's about how to write makefiles in

Re: MAKEFLAGS=-r

On Wed, 2023-07-19 at 16:35 -0400, 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 It works fine; you just didn't do what I said :). I wrote: >

Re: disabling the built-in rules

On Mon, 2023-07-17 at 20:41 +0200, Alejandro Colomar wrote: > BTW, could you point out the problems with the following? > > MAKEFLAGS += --no-builtin-rules > MAKEFLAGS += --no-builtin-variables > MAKEFLAGS += --warn-undefined-variables > > This is what I currently use, and never had a big issue

Re: disabling the built-in rules

On Mon, 2023-07-17 at 19:31 +0200, Bruno Haible wrote: > Except possibly that POSIX does not allow this? Then we would need a > pseudo-target the turns off only the non-standardized part of the > built-in database, say, .NO_GNU_BUILTINS. And users would have to > write: > >   .SUFFIXES: >  

Re: disabling the built-in rules

On Mon, 2023-07-17 at 18:49 +0200, Bruno Haible wrote: > It's also annyoing because it does not work portably: On FreeBSD and > NetBSD, > 'make' gives an error: > >   make: don't know how to make %,v. Stop > > Similarly on OpenBSD: > >   make: don't know how to make %,v (prerequisite of: %) >

Re: MAKEFLAGS=-r

On Mon, 2023-07-17 at 11:45 +0200, Bruno Haible wrote: > Dmitry Goncharov wrote: > > Once the makefile author knows the makefile does not need built-in > > rules, they should add MAKEFLAGS=-r in the makefile and > > this will do a good service to all their users. I'm not sure I've followed the

Re: wildcard and globstar

On Mon, 2023-07-17 at 09:02 -0400, David Boyce wrote: > This raises a side question: it's quite common for glob libraries to > support ** as meaning "search recursively", such as > https://docs.python.org/3/library/glob.html. I'd be a bit surprised > if gnulib's glob implementation didn't support

Re: GNU make troubleshooting

On Sat, 2023-07-15 at 11:28 -0400, Dmitry Goncharov wrote: > Appendix A Debug Output. Thanks for this Dmitry; I spent some time this weekend working on a new section of the manual that would overlap with this. However I will definitely examine your patch and make sure the points you (and

Re: [PING] [PATCH] Escape space in path to $SHELL

On Wed, 2023-07-12 at 17:11 +0200, Torbjorn SVENSSON wrote: > > * src/job.c (construct_command_argv_internal): Escape space in > > $SHELL Unfortunately this is so simple. Currently the spaces in the SHELL variable are not escaped, and things like this work: SHELL := /bin/sh -x and do what

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 17:17 -0400, Jeffrey Walton wrote: > Yes, lots of conditionals and lots of shell'ing, like: > > GREP ?= grep > SED ?= sed > > ifneq ($(wildcard /usr/xpg4/bin/grep),) >   GREP := /usr/xpg4/bin/grep > endif > ifneq ($(wildcard /usr/xpg4/bin/sed),) >   SED := /usr/xpg4/bin/sed

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 16:34 -0400, Jeffrey Walton wrote: > I would add GNU's make lacks minimal debug facilities. I assume this is what Bruno means by his point #3: "Single-stepping or tracing function execution". > That's like peppering a program with printf's. I would like to > understand why

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 21:41 +0200, Bruno Haible wrote: > > I'm not interested in implementing an "interactive" mode for > > single-stepping GNU Make.  Maybe someone else wants to do it but my > > suspicion is that the code changes needed would be massively > > disruptive. > > That sounds like a

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 21:47 +0200, Bruno Haible wrote: > Paul Smith wrote: > > Maybe a version difference.  I'm using 4.4. > > I get the same output with GNU make 4.4 as with 4.3. Apologies for my mistake: I'm using the latest release (4.4.1). I tried your test: $ make --t

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 21:18 +0200, Bruno Haible wrote: > Paul Smith wrote: > > It's not acceptable (to me) to only show the one newest file, not > > all files that are newer than the target, because often you want to > > know all the newer files. > > You say "It'

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 21:05 +0200, Bruno Haible wrote: > $ rm -f mbrtoc32.o > $ make --trace mbrtoc32.o If you remove the target then it should only say that it was rebuilt because the target doesn't exist, regardless of how many other prerequisite are out of date, because you can't even compute

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 20:46 +0200, Bruno Haible wrote: > The " due to: " is useless, since these files > have not changed since the last compilation. (Suggestion: Reduce this > list by showing only the file with the newest timestamp. Files with > older timestamps are redundant.) I can't explain

Re: [gnu-prog-discuss] Blog Post Sighting: Autotools Considered Harmful

On Mon, 2023-07-10 at 12:56 -0400, Stefan Monnier wrote: > > There ARE things we could do with GNU Make still that would make it > > more useful, and faster in some situations, without throwing away > > the millions of existing makefiles and the knowledgebase.  I > > maintain a list of them so if

Re: GNU make troubleshooting

I want to prefix this by saying that there's no question that make's traceability could be improved: I'm not saying nothing needs to be done. On Mon, 2023-07-10 at 20:32 +0200, Bruno Haible wrote: > 1) Print the total of the Makefile and all included Makefiles. >    Like what "gcc -E" does with C

Re: [PING^2] [PATCH 0/6] Fix compilation errors in maintainer mode

On Sat, 2023-07-01 at 10:38 -0400, Paul Smith wrote: > On Sat, 2023-07-01 at 11:50 +0200, Torbjorn SVENSSON wrote: > > Could anyone with write access review these patches and apply them > > for me if there is no comments on them? > > I have them applied locally.  I'll t

Re: [PING^2] [PATCH 0/6] Fix compilation errors in maintainer mode

On Sat, 2023-07-01 at 11:50 +0200, Torbjorn SVENSSON wrote: > Could anyone with write access review these patches and apply them > for me if there is no comments on them? I have them applied locally. I'll try to get them pushed in the next few days.

Re: new feature idea: ingesting processed rulesets

On Sun, 2023-06-11 at 12:29 +, Zoltán Turányi wrote: > My problem is that contrary to the make wisdom of writing a single > Makefile (to which I agree) most projects are still divided into > parts with separate build definitions. One can debate if this is good > or bad - for me it is a

Re: [PATCH] Use UTF-8 active code page for Windows host.

On Sun, 2023-06-18 at 21:33 +0100, Costas Argyris wrote: > Just checking to see if there is still interest in this feature. I had that locally but hadn't had time to test it fully. Pushed now.

Re: [bug #64288] The flag --no-print-directory becomes effective too early

On Wed, 2023-06-14 at 09:52 -0400, Dmitry Goncharov wrote: > Prior versions of make ignored the "MAKEFLAGS += --no-print- > directory" setting. Just to be very clear, it was ignored for _this_ instance of make, but was in effect for any _sub-make_ that was invoked. > if i understood you

Re: [bug #64288] The flag --no-print-directory becomes effective too early

Just to note you can still post comments to bugs in Savannah, and they will be sent out to the list like any other bug, even if they're closed. But discussing on the mailing list directly is fine too! On Fri, 2023-06-09 at 23:46 +0900, Masahiro Yamada wrote: > On Fri, Jun 9, 2023 at 9:39 PM Paul

Re: Unable to cross build for Windows

On Fri, 2023-06-09 at 14:16 +0200, Torbjorn SVENSSON wrote: > The only thing left, that I don't know how to handle, is the use of > O() where the 3rd parameter is not a string literal. > > src/job.c: In function 'create_batch_file': > src/job.c:365:3: error: format not a string literal and no

Re: Unable to cross build for Windows

On Thu, 2023-06-08 at 20:39 +0200, Torbjorn SVENSSON wrote: > > If you get the error about casting _get_osfhandle to HANDLE only > > for the 32-bit build, and you don't care about that build, then > > just ignore it.  But if that error is emitted for the 64-bit build, > > then there's something

Re: new feature idea: ingesting processed rulesets

On Tue, 2023-05-23 at 09:13 +, Zoltán Turányi wrote: > So here is the idea. What if a subsequent invocation of make (in a > subdir)– instead of building the target it is given – would just > parse the makefile, create a full ruleset internally and inject this > ruleset into the parent make’s

Re: Order-only prerequisites

On Wed, 2023-06-07 at 04:20 +0200, Frank Heckenbach wrote: > What I want to achieve is that a and b can be made independently, > but when both of them are made, a is always made first. I assumed > that's what order-only prerequisites are for That's not what it's for. In fact, you can't achieve

Re: [PATCH] Use UTF-8 active code page for Windows host.

On Wed, 2023-05-17 at 22:55 +0100, Costas Argyris wrote: > From a quick search there appear to be many ways > to do this, but some of them are GNU Make-specific, > and I believe these Makefiles (Basic.mk and those > included by it) have to work with any Make, not just > GNU Make. No; those

Re: [PATCH] Use UTF-8 active code page for Windows host.

On Wed, 2023-05-17 at 12:47 +0100, Costas Argyris wrote: > However, when trying to prepare the new patch I realized that > Basic.mk is an untracked file which is listed in .gitignore, so how > would you like me to show you these latest changes? The file to be changed is Basic.mk.template Sorry I

Re: [PATCH] Use UTF-8 active code page for Windows host.

On Mon, 2023-05-15 at 17:48 +0100, Costas Argyris wrote: > As I have said before, I wasn't successful in getting the Basic.mk > approach to work on Windows, as I was getting various errors all > over the place.    They started with CC being undefined, but even > after I defined it to 'gcc' this

Re: [PATCH 0/3] fix clock skew and unlikely timestamp crashes

On Wed, 2023-05-10 at 12:10 -0700, Paul Eggert wrote: > This is a followup to my earlier patch "Two 'make -p' timestamp > issues" > which hasn't been incorporated yet into the master branch. Thanks Paul I'll look at it this weekend.

Re: [PATCH] Use UTF-8 active code page for Windows host.

On Sun, 2023-04-30 at 17:27 +0300, Eli Zaretskii wrote: > > From: Paul Smith > > From: Paul Smith Date: Sun, 30 Apr 2023 09:55:55 - > > 0400 > > > > On Tue, 2023-04-11 at 15:29 +0300, Eli Zaretskii wrote: > > > I agree with the list.  As for Basic.mk, w

Re: New feature request: custom Makefile location

On Fri, 2023-05-05 at 12:47 +0300, Nagy Ákos wrote: > automatic detection: when the make tool don't found the makefile in > local folder, can check an environment variable (ex: > MAKEFILE_LOCATION) and if exist, can use it > > manual flag: can add a new configuration flag to make: make >

Re: [PATCH] Use UTF-8 active code page for Windows host.

On Tue, 2023-04-11 at 15:29 +0300, Eli Zaretskii wrote: > I agree with the list.  As for Basic.mk, we can forget about it from > my POV.  Paul should make the call, but from my POV that file was > unmaintained and therefore unsupported. Why do we think it's unmaintained / unsupported? It worked

Re: Build gnu cmake sources

On Mon, 2023-04-10 at 01:51 +0300, Дмитрий Мозулёв wrote: > I would like to build your GNU Make utility from source for 5 > platforms: Windows x64, Linux x64/arm64 and macOS x64/arm64. > Unfortunately, I'm having trouble. Hi; please use the bug-make@gnu.org mailing list for questions about

Re: [PATCH] Use UTF-8 active code page for Windows host.

On Fri, 2023-04-07 at 08:29 -0400, Paul Smith wrote: > > Also, I'm still waiting for Paul to approve the changes to Posix > > configury part of your patch. > > Sorry I will make every effort to get to it today. The configure part looks OK to me. This change to Makefile.

Re: [PATCH] Use UTF-8 active code page for Windows host.

On Thu, 2023-04-06 at 22:32 +0300, Eli Zaretskii wrote: > > From: Costas Argyris > > Date: Thu, 6 Apr 2023 22:04:48 +0300 > > Cc: bug-make@gnu.org, Paul Smith > > > > Hi and sorry to bother you again. > > > > I haven't received any response so > >

The --warn / .WARNINGS feature

I pushed my changes to implement the --warn / .WARNINGS feature. I hope people find them useful. As of now there are only 3 possible warnings, but I will be looking through other warnings that might be useful to control. There is one major caveat to this: currently it's not possible to set

Re: `make check -j` fails when building GNU Make from source

On Mon, 2023-04-03 at 14:36 +0200, Alejandro Colomar wrote: > -  Being part of the make targets, it would enable running them in >    parallel, taking around 1/4th the time it takes now. Up until this morning this could not work because all the tests run in the same directory and they create

Re: `make check -j` fails when building GNU Make from source

On Sun, 2023-04-02 at 18:14 +0200, Alejandro Colomar wrote: > I wonder if you could use the Makefile to run the tests, rather > than calling a script from a .PHONY target that runs them all the > time.  Why not run them only once?  You can touch empty files > when a test succeeds to make make(1)

Re: `make check -j` fails when building GNU Make from source

On Sun, 2023-04-02 at 16:13 +0200, Alejandro Colomar wrote: > I can reproduce it by running `make check`, interrupting it > at this specific point, and then running again `make check` > (no -j needed): This is a known limitation with the test suite.

Re: `make check -j` fails when building GNU Make from source

On Sun, 2023-04-02 at 14:52 +0200, Alejandro Colomar wrote: > If I build make from source and run the checks in parallel, some > fail. Is this expected, or is it a bug in the Makefile? The test suite is invoked as a single target, so there's no way that enabling parallelism could impact it.

Re: Quotes Bug

On Thu, 2023-03-30 at 22:05 +0300, Eda Çelik wrote: > Hello, I'm a master student at Çanakkale Onsekiz Mart University in > Turkey. I'm trying to use rvfit code but this code written GNU data > language. I installed GDL but rvfit code is not working. Code and > error by: > GDL> >

Re: [PATCH] Use UTF-8 active code page for Windows host.

I apologize for being incommunicado: for the last week I've been fighting the mother of all head colds. The only good thing I can say about it is that it was not COVID. I'm sort of back on my feet. On Sat, 2023-03-25 at 23:12 +, Costas Argyris wrote: > and then from README.W32 -> Building

Re: [PATCH] Use UTF-8 active code page for Windows host.

On Tue, 2023-03-21 at 12:52 +, Costas Argyris wrote: > When trying from git, which was my first attempt, I was getting > compilation warnings which were turning themselves into errors, > so I never managed to build. > > When I used the sources extracted from the tarball though, this > simply

Re: [PATCH] Use UTF-8 active code page for Windows host.

On Sun, 2023-03-19 at 16:47 +0200, Eli Zaretskii wrote: > If we add tests for this feature (and I agree it's desirable), we > should generate the files with non-ASCII names for those tests as > part of the test script, not having them ready in the repository and > the tarball. Agreed for sure;

  1   2   3   4   5   6   7   8   9   10   >