makefiles and generates missing or out-of-date
> makefiles and then if any makefile was updated, make re-executes
> itself and does all that again. This time there should be no outdated
> makefiles and make will proceed to build the intended targets.
> So, as long as you avoid marking inc
t; what is the preferred way to ensure
> that generated files are built in a separate step before Make considers
> which targets are out of date during the main build?
Make reads all makefiles and generates missing or out-of-date
makefiles and then if any makefile was updated, make re-executes
its
On Wed, 2 Jul 2025 at 20:11, Tim Murphy wrote:
> On Wed, 2 Jul 2025 at 22:40, Bahman Movaqar wrote:
>
>> Somehow in the same vein is the work I did in bmakelib:
>> https://github.com/bahmanm/bmakelib/blob/main/doc/logged.md
>>
> That library is impressive.
>
Thanks. So much PROD-grade pain have
On Thu, 2025-07-03 at 14:38 +0200, wrotycz wrote:
> > It's not expected that users look at the value of MAKEFLAGS that
> > make itself sets (so, the version generated in a recipe). That
> > format, although documented, is technically internal to make
>
> I was refering to C. Funk's proposition to
> I'm not sure what "documentation, not manual" refers to.
Maybe you mean the man page? Yes. ~~~ $ man man General
Commands Manual man - format and display the on-line manual pages ~~~
According to this man pages are manuals. > It's not expected that
users lo
On Wed, 2 Jul 2025 at 22:40, Bahman Movaqar wrote:
> Somehow in the same vein is the work I did in bmakelib:
> https://github.com/bahmanm/bmakelib/blob/main/doc/logged.md
>
That library is impressive.
I wondered if GNU make could benefit from a function that fetches the
current time - this migh
Somehow in the same vein is the work I did in bmakelib:
https://github.com/bahmanm/bmakelib/blob/main/doc/logged.md
On another note, I think for such a feature to be added to Make it should
be a bit more abstract. A couple of ideas that crossed my mind:
- The timestamp format should either be conf
On Wed, 2025-07-02 at 00:03 +0200, wrotycz wrote:
> Tried to get what the `MAKEFLAGS' is but documentation, not manual is
> not very helpful.
I'm not sure what "documentation, not manual" refers to. Maybe you
mean the man page? The man page is not intended to describe everything
about makefiles
Hi :-)
That's a cool idea. Can you send us the diff or a link to the diff?
Regards,
Timothy Murphy
On Wed, 2 Jul 2025 at 14:00, xf liao wrote:
> Hello everyone, my name is Nico, and I’m from China. I’m a senior IT
> systems architect, and I use Make in my daily work to build IT environments.
See the last 5 paragraphs, starting with: The MAKEFLAGS variable can also be
useful if you want to have certain options, such as ‘-k’ (see Summary of
Options), set each time you run make.Tried to get what the `MAKEFLAGS'
is but documentation, not manual is not very helpful. Info is bette
Zack Weinberg (30 June 2025 19:23) wrote:
> It doesn't have to control what happens inside a shell command. All
> it has to do is split the recipe into individual commands *before*
> expanding anything -- this is perfectly possible, since \n and ;
> *don't* separate commands when they come from ex
On Mon, Jun 30, 2025, 9:14 AM Zack Weinberg wrote:
> Follow-up Comment #5, bug #67265 (group make):
>
>
> > We're not going to make $(file...) a special case that expands
> differently
> > than everything else.
>
> I'm surprised you insist on this. There is plenty of precedent for using
> the
>
On Mon, 2025-06-30 at 15:03 -0400, Zack Weinberg wrote:
> On Mon, Jun 30, 2025, at 2:21 PM, Paul D. Smith wrote:
> > Follow-up Comment #6, bug #67265 (group make):
> > Make's expansion rules are very simple. When some text undergoes
> > expansion, make goes through the text and looks for un-escape
On Mon, Jun 30, 2025, at 2:21 PM, Paul D. Smith wrote:
> Follow-up Comment #6, bug #67265 (group make):
>> If you are determined that anything that looks like $(...) or ${...} must be
>> consumed by expansion, you could get the same effect by having $(file
>> REDIRECTION, CONTENTS) expand to a diff
On Mon, 2025-06-30 at 13:23 -0400, Zack Weinberg wrote:
> > It's not $(file) that is causing this effect it's how all make
> > functions work of any kind. There is always expansion just before a
> > command is executed. When a command is sent to the shell make has
> > no further control of it.
>
>
On Mon, Jun 30, 2025, at 1:43 PM, Tim Murphy wrote:
> On Mon, 30 Jun 2025 at 18:14, Zack Weinberg wrote:
>> p.s. I do insist that this is a bug, not a feature request. The existing
>> behavior is strictly less useful than the requested behavior, and surprising
>> to boot.
>
> If I understand you
On Mon, Jun 30, 2025, at 12:55 PM, Tim Murphy wrote:
> How can make control what happens inside a shell command? How can
> make wait until mkdir is executed by the shell and then expand $(file)
> before the next shell command executes?
It doesn't have to control what happens inside a shell comman
On Mon, 30 Jun 2025 at 18:14, Zack Weinberg wrote:
>
> p.s. I do insist that this is a bug, not a feature request. The existing
> behavior is strictly less useful than the requested behavior, and
> surprising
> to boot.
If I understand you then you want to use $(file) to get around the
command
On Mon, 2025-06-30 at 17:55 +0100, Tim Murphy wrote:
> That cannot work logically. How can make control what happens inside
> a shell command? How can make wait until mkdir is executed by the
> shell and then expand $(file) before the next shell command executes?
I think the ask is that the expan
On Mon, 30 Jun 2025, 16:41 Zack Weinberg, wrote:
> Follow-up Comment #3, bug #67265 (group make):
>
> 1. The point of the bug report is that $(file) *should be* processed later
> than other $(...) constructs. Having said that, it would probably be
> sufficient, and perhaps a less invasive change
> From: Espen Ottar
> CC: "bug-make@gnu.org"
> Date: Mon, 30 Jun 2025 13:39:30 +
>
> Ok, my bad. I was using make 3.81 from
> https://gnuwin32.sourceforge.net/packages/make.htm
Try the one from ezwinports site.
> From: Espen Ottar
> Date: Mon, 30 Jun 2025 07:47:41 +
>
> On Windows it is possible to enable case sensitivity on a per-folder basis .
> (using fsutil.exe)
> When case sensitivity is enabled, make fails to read "Makefile" (with capital
> M)
> The workaround is to use "make -f Makefile" bu
Paul Smith writes:
> But I agree with, and others have requested that, parallelism being
> limited in some way by available _memory_ and not just available CPU:
> this seems very reasonable. The fly in the ointment is that, even
> moreso than CPU, memory is not allocated up-front and by the time
On Fri, 2025-06-27 at 10:18 -0700, Collin Funk wrote:
> If one wants to add a default value because they know it will always
> work with their system they can easily add this to their ~/.profile:
>
> export GNUMAKEFLAGS="$((2 * `nproc`))"
>
> Assuming this is the value they want (and 'nproc'
Paul Smith writes:
> On Fri, 2025-06-27 at 14:31 +0200, wrotycz wrote:
>> > Of course none of this is very relevant to the issue under
>> > discussion.
>>
>> I'm lost now.
>
> What I'm trying to say is that the exact number of jobs used as a
> default is not really that important. I have no pro
On Fri, 2025-06-27 at 18:41 +0200, wrotycz wrote:
> > The other is that it's difficult to set a generic value for "-j"
> > (say in a MAKEFLAGS environment variable, or even in the makefile
> > itself) that works across a variety of systems with different CPU
> > counts.
>
> What is MAKEFLAGS? As f
The other is that it's difficult to set a generic value for "-j"
(say in a MAKEFLAGS environment variable, or even in the makefile itself)
that works across a variety of systems with different CPU counts. What is
MAKEFLAGS? As far as I understand it is command line in form of environmental
> The other is that it's difficult to set a generic value for
"-j" (say > in a MAKEFLAGS environment variable, or even in the
makefile itself) > that works across a variety of systems with different
CPU counts. What is MAKEFLAGS? As far as I understand it is command line in
form of environm
On Fri, Jun 27, 2025 at 4:23 AM Paul Smith wrote:
>
> On Fri, 2025-06-27 at 04:09 -0800, Britton Kerin wrote:
> > The many answers here show the appetite for finding out about
> > variables:
> > https://stackoverflow.com/questions/16467718/how-to-print-out-a-
> > variable-in-makefile
> >
> > A
On Fri, 2025-06-27 at 14:31 +0200, wrotycz wrote:
> > Of course none of this is very relevant to the issue under
> > discussion.
>
> I'm lost now.
What I'm trying to say is that the exact number of jobs used as a
default is not really that important. I have no problem saying that
the default num
I don't see any need to be aggressive in your response. You're right,
it came out clumsily. I can get -j almost 2x the number of CPU threads
before builds start slowing down, Maybe that 2*nproc is not that bad
estimate, if it comes out I experiments. (b) there's a lot of latency of
On Fri, 2025-06-27 at 04:09 -0800, Britton Kerin wrote:
> The many answers here show the appetite for finding out about
> variables:
> https://stackoverflow.com/questions/16467718/how-to-print-out-a-
> variable-in-makefile
>
> A variety of different approaches are represented there, but none o
> Emotive terminology like "ludicrous" doesn't encourage a
constructive response. You're right. I don't feel in English so it
may be too strong or even not to the point. >> Here is [a] slightly
improved test script[.]>... yet I didn't see one. Script is here:
lists.gnu.org https://li
On Thu, 2025-06-26 at 19:21 +0200, wrotycz wrote:
> > > There are plenty of scenarios where using more jobs than
> > > processor threads results in faster builds: it all depends
>
> You say that because you have tested it or because you believe it?
> I have tested it, But let's bust this ludicrous
> But let's bust this ludicrous idea and show us a test that disproves me
Emotive terminology like "ludicrous" doesn't encourage a constructive response.
If I understand correctly, I think you're describing your own proposal with
that term, as a rhetorical device. It wasn't ludicrous and Paul
Mentioned script.
#!/bin/sh
#URL=http://ftp.gnu.org/gnu/make/make-4.4.1.tar.gz # 34 .o files
#URL=https://mirrors.dotsrc.org/gnu/make/make-4.4.1.tar.gz
URL=https://mirrors.dotsrc.org/gnu/bash/bash-5.2.tar.gz # 193
#URL=https://mirrors.dotsrc.org/gnu/coreutils/coreutils-9.5.tar.gz # ~1859 .c
#URL=h
> There are plenty of scenarios where using more jobs than processor threads
results in faster builds: it all depends You say that because you have tested
it or because you believe it? I have tested it, But let's bust this
ludicrous idea and show us a test that disproves me. Here is slightly
On Wed, 2025-06-25 at 13:34 +0200, wrotycz wrote:
> At the moment, though this moment lasts for decades now, -j/--jobs
> without argument starts infinite number of parallel jobs.
> Practice shows that compilation with jobs bigger than number of
> available threads is not faster in any way, only use
On Sat, Jun 21, 2025 at 1:38 PM WaitronCharm wrote:
>
> Are you guys also reading this line as the relevant argument applying to my
> case:
>
> https://pubs.opengroup.org/onlinepubs/9799919799/utilities/make.html
>
> 'Include lines and rules for creating dynamic include files do not depend
> [di
p Guenther
wrote:
>
>
> -- Forwarded message --
> From: Philip Guenther
> Date: Thursday, June 19, 2025
> Subject: Re-executing..., when and when not?
> To: WaitronCharm
>
>
> On Thu, Jun 19, 2025 at 2:31 PM WaitronCharm wrote:
> >
>
On Thu, 2025-06-19 at 20:59 +, WaitronCharm via Bug reports and
discussion for GNU make wrote:
> Yes, thank you. It looks like with the 1st execution not only
> included files are re-made and a 2nd execution started but also
> (still in the 1st execution) other targets (targets whic
(Sigh, I sent two messages off-list because of bad gmail UX. Forwarding to
the list…)
-- Forwarded message --
From: *Philip Guenther*
Date: Thursday, June 19, 2025
Subject: Re-executing..., when and when not?
To: WaitronCharm
On Thu, Jun 19, 2025 at 11:13 AM WaitronCharm via
-- Forwarded message --
From: *Philip Guenther*
Date: Thursday, June 19, 2025
Subject: Re-executing..., when and when not?
To: WaitronCharm
On Thu, Jun 19, 2025 at 2:31 PM WaitronCharm wrote:
>
> Thank you. Yes exactly that happens: 't4' is re-made in the 1st
Thank you, I got valuable feedback: The 't2' prerequisite of 't4' considers
differently the timing internals of the 'make' execution and re-executions.
Practically 'make' refers to prerequisites in case of include file remakes in
regards to pre and post
't4' is re-made in the 1st execution based on a -- by now -- outdated recipe.
And why 'make' does not wait with that for the 2nd execution?
I guess because 't9' is also included and 't9' has 't4' as prerequisite.
And how to resolve this without
Yes, thank you. It looks like with the 1st execution not only included files
are re-made and a 2nd execution started but also (still in the 1st execution)
other targets (targets which are not included) also re-made by recipes now
outdated.
Is this how 'make' works?
Thought that one
27; processes). Issue is that the 'make' re-run is not
> triggered as ... I wished.
I'm not sure I understood exactly everything about your post but the
rules for how things are remade are pretty simple and GNU Make has
always worked like this:
First all makefiles are parsed. Th
Hi everyone
Story is the following. There is a 'makefile' which includes a couple of
others, some are itself generated by the same 'make' run (i.e. NO recursive
'make' processes). Issue is that the 'make' re-run is not triggered as ... I
wished.
Int
On 6/10/25 13:44, Nathan Zacarias Chrestani wrote:
Hello.
I did the GNU Make logo, did you like it?
No.
On Sun, Jun 8, 2025 at 12:35 AM wrote:
> I am a happy user of make (various implementations) for 25 years. Today I
> learned that "multiple target rules" don't do what I thought they do.
> While dealing with this, I think I've found a bug, either in code or in
> documentation. Plus I have a relate
On Sun, 2025-06-08 at 13:04 +0200, Thierry Mould via Bug reports and
discussion for GNU make wrote:
> I install make on my home directory. No fatal error.
> Now I ‘ll try to use make (correctly).
You are using a MacOS system. MacOS uses a case-insensitive
filesystem, and you've mismatched the cas
> I think static pattern rules without recipes are rare (at least I've
> never seen or used one)
I could quickly lay my hands on what looks like a handful:
./subrules.make:384:$(SOFTWARE)$(PROJPATH)/%: %;
./subrules.make:392:$(FLEX_GEN_CPP): %.gen.cpp: generated/regenerated.%
./subrules.make:393
On Thu, 2025-06-05 at 21:43 +0200, Denis Excoffier wrote:
> jupiter% touch foo100.z0 bar200.z0; rm -f foo100.z1 bar200.z1
> jupiter% make
> foo100 (foo100 is expected and foo100 is obtained)
> 200 (bar200 is expected but 200 is obtained instead)
> jupiter% make --version | head -1
> GNU Make 4.4.1
On Wed, 28 May 2025 at 21:39, Jonathan Wakely wrote:
>
> I see that there was a report (and a workaround) for $(realpath foo//)
Oops, I meant to link to that:
https://lists.gnu.org/archive/html/bug-make/2019-09/msg00063.html
> on AIX, but AIX realpath has bigger problems. Paths containing //..
Hi Marek! Please choose just onee mailing list to ask your question,
rather than sending it to multiple lists. Either one would be
appropriate for this question IMO.
On Wed, 2025-04-30 at 12:15 +, Marek Küthe wrote:
> I am currently taking a closer look at the `patsubst` function in
> `make
On Thu, 2025-04-24 at 11:45 +0200, Gabriele Santandrea wrote:
> Greetings,
> I am trying to learn make, going through the documentation and even
> writing a repository containing examples copied, extrapolated or
> commented from the GNU make docs.
>
> In Section 5.4.1 when running the .NOTPARALLEL
On Tue, Apr 22, 2025 at 8:54 PM Shim Manning wrote:
>
> Minimal test. Generates a list of 1000 prerequisites.
>
> list := $(shell for n in $$(seq 1 1000); do echo file_$$n; done)
> all: .EXTRA_PREREQS := $(list)
> all:
> echo "fin"
>
> And tes making a copy of the table appears to fix it
Thank y
Minimal test. Generates a list of 1000 prerequisites.
list := $(shell for n in $$(seq 1 1000); do echo file_$$n; done)
all: .EXTRA_PREREQS := $(list)
all:
echo "fin"
And tes making a copy of the table appears to fix it
On Sat, Apr 19, 2025 at 9:26 PM Dmitry Goncharov
wrote:
> On Fri, Apr 18,
On Fri, Apr 18, 2025 at 11:12 PM Shim Manning wrote:
>
> Seems that using .EXTRA_PREREQS can cause a segfault under the right
> conditions.
...
> snap_deps
> hash_map_arg (loop happens here)
> snap_file
> expand_extra_prereqs
> enter_file
> hash_insert_at
> hash_rehash (loop no longer valid)
>
Thanks for the feedback. At first glance a merge would make sense to
me. I'll play with it some, and contact the author.
-Josh
On Sun, Apr 6, 2025 at 12:06 AM carl hansen wrote:
>
> FYI
>
> https://gmsl.jgc.org/
> GNU Make Standard Library
> "The GNU Make Standard Library (GMSL) is a collection o
and file CC.py
reads from file F.txt (and CC.py declares its INPUTS= as described below). Now
if you modify file F.txt or CC.py, any rule that runs BBB.py will automatically
be re-run in the correct order when you use make, even if you didn't directly
edit BBB.py.
In tests with over 1000 files the
also of interest:
https://github.com/Trepan-Debuggers/remake
On Sun, Apr 6, 2025 at 8:28 AM Bahman Movaqar wrote:
>
> Hey all 👋️
>
> Very interesting topic!
>
> I thought I'd share my own attempt at having a collection of useful utilities
> for my Makefiles 😅️
Slightly more on the datastucture side there's the very nice-looking
GNU Make Standard Library
h
Hey all 👋️
Very interesting topic!
I thought I'd share my own attempt at having a collection of useful utilities
for my Makefiles 😅️
https://github.com/bahmanm/bmakelib
_The minimalist Make standard library you'd always wished for!_
It's fully tested via the CI pipeline¹ and available as a Dock
FYI
https://gmsl.jgc.org/
GNU Make Standard Library
"The GNU Make Standard Library (GMSL) is a collection of functions
implemented using native GNU Make functionality that provide list and
string manipulation, integer arithmetic, associative arrays, stacks,
and debugging facilities. The GMSL is r
> I was wondering about the possibility of adding, as a feature to make,
> the addition of a standard makefile fragments library. I have started
> such a library.
> https://gitlab.com/enoch247/fracture
That is a nice initiative! Regardless if such a work should be included in
distributions of GNU
On Wed, 2025-03-19 at 09:58 -0400, Dmitry Goncharov wrote:
> What do you think we should do?
I think we should either do nothing and leave it as it is, or try to
provide the functionality that Britton is looking for (the behavior in
my description).
The questions are, is this behavior strictly be
On Mon, 2025-03-17 at 21:16 -0400, Dmitry Goncharov wrote:
> > To build target A:
> > - First try to build all NON-ORDER-ONLY prerequisites
> > - Compare the modification time of all NON-ORDER-ONLY prerequisites
> > - If any NON-ORDER-ONLY prerequisite is newer than A:
> > - Try to build all ORD
> On Mar 22, 2025, at 3:51 PM, Tim Murphy wrote:
>
> I cannot at the moment see this being added to make proper - at least not for
> some time.
I don't see why. This seems like useful general-purpose functionality.
I would encourage creating a version that can be added & asking to get it ad
On Thu, 20 Mar 2025 at 21:07, David A. Wheeler
wrote:
>
>
> > On Mar 18, 2025, at 1:21 PM, Tim Murphy wrote:
> >
> > I've recently updated and rebased my experimental fork of make with the
> branch that dumps the internal database of the makefile to JSON format
> files.
>
> I would *dearly* love
> On Mar 18, 2025, at 1:21 PM, Tim Murphy wrote:
>
> I've recently updated and rebased my experimental fork of make with the
> branch that dumps the internal database of the makefile to JSON format files.
I would *dearly* love to have the ability to receive a dump of the makefile
database i
On Wed, Mar 19, 2025 at 5:59 AM Dmitry Goncharov
wrote:
>
> On Tue, Mar 18, 2025 at 8:06 AM Paul Smith wrote:
> > I see from the patch: you don't mean "never" you mean, only if the
> > prerequisite does not exist will it be updated.
>
> Right.
>
> > I agree this preserves probably the most common
On Tue, Mar 18, 2025 at 8:06 AM Paul Smith wrote:
> I see from the patch: you don't mean "never" you mean, only if the
> prerequisite does not exist will it be updated.
Right.
> I agree this preserves probably the most common reason for using OO
> prereqs (to create directories)
This preserves
I've recently updated and rebased my experimental fork of make with the
branch that dumps the internal database of the makefile to JSON format
files.
It handles more aspects of the database but not all of them. Listing
directories still doesn't work yet. I don't have a test set to try it on so
it
On Mon, Mar 17, 2025 at 8:12 AM Paul Smith wrote:
> The question we have think carefully about is what sort of backward-
> compatibility issues, if any, we could introduce. Are there situations
> where people are relying on the current behavior?
It is possible that someone relies that running 'm
On Mon, Mar 17, 2025 at 4:12 AM Paul Smith wrote:
>
> On Sat, 2025-03-15 at 08:28 -0400, Dmitry Goncharov wrote:
> > On Mon, Mar 10, 2025 at 8:12 AM Paul Smith wrote:
> > >
> > > On Sat, 2025-03-08 at 11:34 -0900, Britton Kerin wrote:
> > > > What confuses me is that since the explicitly requeste
AM
To: Cook, Malcolm ; bug-make@gnu.org
Subject: Re: order-only prerequisites themselves get rebuilt when not needed
The patch attached to the savannah issue Dmitry provided below does
include a doc change. I haven't reviewed it yet.
Basically the current behavior is:
To build target A:
-
ers get up to speed with the proposal???
>
>
>
> From: bug-make-bounces+mec=stowers@gnu.org
> Sent: Monday, March 17, 2025 7:10:06 AM
> To: bug-make@gnu.org
> Subject: Re: order-only prerequisites themselves get rebuilt when not
> needed
>
> On Sat, 2025-03-15
get up to speed with the proposal???
Get Outlook for Android<https://aka.ms/AAb9ysg>
From: bug-make-bounces+mec=stowers@gnu.org
on behalf of Paul Smith
Sent: Monday, March 17, 2025 7:10:06 AM
To: bug-make@gnu.org
Subject: Re: order-only prerequ
On Sat, 2025-03-15 at 08:28 -0400, Dmitry Goncharov wrote:
> On Mon, Mar 10, 2025 at 8:12 AM Paul Smith wrote:
> >
> > On Sat, 2025-03-08 at 11:34 -0900, Britton Kerin wrote:
> > > What confuses me is that since the explicitly requested foo
> > > exists and isn't out of date with respect to any n
On Mon, Mar 10, 2025 at 8:12 AM Paul Smith wrote:
>
> On Sat, 2025-03-08 at 11:34 -0900, Britton Kerin wrote:
> > What confuses me is that since the explicitly requested foo exists
> > and isn't out of date with respect to any non-order-only prereqs (in
> > the example it doesn't have any) and the
> On Mar 12, 2025, at 11:57 AM, Paul Smith wrote:
>
> On Wed, 2025-03-12 at 15:05 +, Yao Shuangjie wrote:
>> We are cybersecurity researchers from the Hong Kong University of
>> Science and Technology. We found several security violations of
>> undefined behaviors in GNU make 4.4.1 using o
On Wed, 2025-03-12 at 15:05 +, Yao Shuangjie wrote:
> We are cybersecurity researchers from the Hong Kong University of
> Science and Technology. We found several security violations of
> undefined behaviors in GNU make 4.4.1 using our novel symbolic
> execution technique several months ago. Th
On Mon, 2025-03-10 at 12:38 -0800, Britton Kerin wrote:
> I would expect make to remove trailing comments and then strip
> surrounding white space from variable definitions as usual but it
> seems that the comments prevent further stripping:
Comments don't prevent stripping; values in assignments
On Sat, 2025-03-08 at 11:34 -0900, Britton Kerin wrote:
> What confuses me is that since the explicitly requested foo exists
> and isn't out of date with respect to any non-order-only prereqs (in
> the example it doesn't have any) and therefore isn't getting rebuilt,
> I wouldn't expect there to be
On Fri, Mar 7, 2025 at 4:59 AM Paul Smith wrote:
>
> On Thu, 2025-03-06 at 13:28 -0900, Britton Kerin wrote:
> > In this example, I would not expect bar to be updated due to
> > actual_source when foo is requested. The timestamp dependency chain
> > should be broken between foo and bar and Make s
On Thu, 2025-03-06 at 13:28 -0900, Britton Kerin wrote:
> In this example, I would not expect bar to be updated due to
> actual_source when foo is requested. The timestamp dependency chain
> should be broken between foo and bar and Make should be able to
> figure that out when handling an explicit
On Wed, 2025-03-05 at 18:23 -0500, Dmitry Goncharov wrote:
> There is a buffer overflow when shellflags contains characters
> special to shell, like =.
> See https://savannah.gnu.org/bugs/?65588.
I got really fed up with the current command line parser and I have a
fully-rewritten version that is
> From: Jeffrey Walton
> Date: Wed, 19 Feb 2025 09:04:27 -0500
> Cc: Eldred HABERT , bug-make@gnu.org
>
> On Wed, Feb 19, 2025 at 7:41 AM Eli Zaretskii wrote:
> >
> > It is not that simple. GNU Make uses 'stat' to retrieve the time
> > stamp of files, and the Windows implementation of 'stat' re
On Wed, Feb 19, 2025 at 7:41 AM Eli Zaretskii wrote:
>
> > Date: Tue, 18 Feb 2025 22:06:11 +0100 (GMT+01:00)
> > From: Eldred HABERT
> >
> > Hello!
> >
> > I am having an issue that some versions of Make never stop on a Make file I
> > made, but only on Windows.
> > https://github.com/ISSOtm/gb-
> Date: Tue, 18 Feb 2025 22:06:11 +0100 (GMT+01:00)
> From: Eldred HABERT
>
> Hello!
>
> I am having an issue that some versions of Make never stop on a Make file I
> made, but only on Windows.
> https://github.com/ISSOtm/gb-starter-kit/issues/1#issuecomment-1793775226
> I have traced the issue
On Mon, 2025-02-10 at 03:40 +0900, Masahiro Yamada wrote:
> ifeq ($(SUBMAKE),)
> MAKEFLAGS += --no-print-directory
> MAKEFLAGS += -rR
> all:
> @echo in top: MAKEFLAGS=$(MAKEFLAGS)
> $(MAKE) -w SUBMAKE=1
> else
> all:
> @echo in submake: MAKEFLAGS=$(MAKEFLAGS)
> endif
>
>
>
On Mon, 2025-02-10 at 02:01 +0900, Masahiro Yamada wrote:
> The first word in $(MAKEFLAGS) is not a group of short options.
>
> $(MAKE) MAKEFLAGS=--no-print-directory SUBMAKE=1
If you override the value of MAKEFLAGS as a command-line variable
assignment, then the value you specified is th
On Sun, Feb 9, 2025 at 12:04 PM Masahiro Yamada wrote:
...
> This is no longer true when MAKEFLAGS is set
> via the command line.
A command line definition of MAKEFLAGS is a bad idea.
https://savannah.gnu.org/bugs/?62469
regards, Dmitry
On Sun, Feb 9, 2025 at 12:18 PM Himanshu Pradeep
wrote:
>
> Hello Team
> I hope this email finds you well
>
> I was installing CARLA Simulator, building from source for windows. I am
> following all the guidelines shown on the website Windows build - CARLA
> Simulator . I am running Make version
On Tue, 2025-01-21 at 22:00 +0100, Michael Olbrich wrote:
> Since c3b39d0654c3 "[SV 62514] Honor command line interface flags",
> make incorrectly filters oute multiple -C arguments with the same
> directoy string:
Oh that's bad. Thanks for the patch!
Basile Starynkevitch (13 January 2025 11:51) wrote:
> My suggestion is that make --version would show the .FEATURES
Perhaps limit that to make -v --version ?
Eddy.
On Sat, Jan 11, 2025 at 3:40 AM Pete Dietl wrote:
> You need a recursive let if you want to be able to define inner functions,
> like a helper function.
That much I understand, but I cannot come up with many scenarios where
that would make sense in Make. Whenever the definition of the inner
func
Jouke,
You need a recursive let if you want to be able to define inner functions,
like a helper function.
On Mon, Dec 30, 2024, 5:21 AM Jouke Witteveen wrote:
> Hi Pete,
>
> On Thu, Dec 26, 2024 at 7:44 AM Pete Dietl wrote:
> > I propose adding a "letrec" builtin to complement the "let" builti
Hi Pete,
On Thu, Dec 26, 2024 at 7:44 AM Pete Dietl wrote:
> I propose adding a "letrec" builtin to complement the "let" builtin.
> The "let" builtin does not allow one to define inner functions or
> mutually recursive definitions.
Can you maybe help me understand why this functionality would be
1 - 100 of 7508 matches
Mail list logo
