Is there anyone out there still building GNU Make on VMS?
I've been looking at the code and, although it's a bit hard to tell
through the thicket of #ifdefs in the code, it appears to me like GNU
Make won't compile successfully on VMS as of GNU Make version 4.3 where
it looks like I broke the comp
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
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 :-/.
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
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
On Mon, 2024-12-09 at 01:49 -0800, Pete Dietl wrote:
> Mon, 9 Dec 2024 10:37:14 +0100, Jouke Witteveen 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 f
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
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
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
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
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
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 un
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
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
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
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
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
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
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
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";
> |
On Mon, 2024-07-01 at 13:51 -0700, Albaro Pereyra wrote:
> Thanks for reaching out. I have reached out to the maintainers of
> drogon-assist. They said it was out of their scope to diagnose the
> issue with my make. Basically saying it works on their computer and
> don't know why it doesn't work
On Sun, 2024-06-30 at 23:20 -0700, Albaro Pereyra wrote:
> I am unable to make drogon-assist.
> https://github.com/drogonframework/drogon-assist
>
> I am running on WSL2 ubuntu
> Linux HP-14-64GB 5.15.153.1-microsoft-standard-WSL2 #1 SMP Fri Mar 29
> 23:14:13 UTC 2024 x86_64 x86_64 x86_64 GNU/Linu
On Fri, 2024-06-21 at 09:11 -0400, Dmitry Goncharov wrote:
> i hope, Paul approves adding tests of this nature.
I have no problems with adding unit tests, as long as we can find a way
to integrate it into the test suite in a reasonable way.
But this particular thing doesn't really feel like a "te
On Mon, 2024-05-20 at 07:25 +0200, Henrik Carlqvist wrote:
> On Sun, 19 May 2024 18:02:45 -0400 (EDT)
> > Many programs use a single dash to mean "read from stdin" but make
> > doesn't
> > do this.
>
> Yes, it does:
>
> -8<
> nazgul:/tmp> make -f -
Yes, if
On Mon, 2024-05-13 at 22:05 -0400, Dmitry Goncharov wrote:
> On Wed, May 8, 2024 at 2:04 PM JZB wrote:
> >
> > I have a GNU make-based build system wherein I would like for
> > any/all
> > GNU make-detected circular dependencies to be treated as a hard
> > error,
> > i.e., fail [immediately], rat
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 of t
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 s
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 CFLA
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
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 u
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
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 D
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 http://make.
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 == '
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
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.
>
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 and
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 regres
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 first o
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 information
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
f
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. Since
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
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 introduce
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 :=
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, b
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:
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".
>
> > A
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 o
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 ar
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
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 li
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 no
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 != exam
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 cont
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 (
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 is
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 en
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
> suppo
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
> >
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 conditional
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 "?=" wh
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
> https://savannah.gnu.
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
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 is
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.
>
> T
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, t
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
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 vers
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
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 t
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. Als
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
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 --d
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 case
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
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
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
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 general.
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:
> .
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 w
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:
> .NO_GN
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: %)
>
>
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 ent
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 t
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
everyone
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 y
On Tue, 2023-07-11 at 10:01 -0400, Jeffrey Walton wrote:
> > But, what about this do you want to know?
>
> I want to see an output for the evaluation of each statement, like
> what I would see with 'set -x'. I need to know where something goes
> sideways when shell'ing out in a pipe.
If what you
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
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 a
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 di
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:
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 &quo
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 t
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 wh
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 t
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
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
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.
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 requirem
1 - 100 of 1512 matches
Mail list logo
