On Thu, 2025-09-11 at 23:00 +0200, Alejandro Colomar wrote:
> Are target-specific variables only available in the recipe?
Yes, they are (your original example didn't say that you wanted to use
the variable in the prerequisites list as well):
https://www.gnu.org/software/make/manual/html_node/Targ
On Wed, 2025-09-10 at 23:38 +0200, Alejandro Colomar wrote:
> The reason I want to be able to undefine the variable name is to not
> need to come up with unique names in variables used within a recipe.
> That's why I immediately undefine it; to be able to reuse the name,
> making sure that old valu
On Wed, 2025-09-10 at 22:33 +0200, Alejandro Colomar wrote:
> alx@debian:~/tmp/bug$ cat Makefile | nl -ba
> 1 MAKEFLAGS += --warn-undefined-variables
> 2
> 3 foo := foo
> 4
> 5 all:; echo $(foo)
> 6
> 7 undefine foo
> alx@debian:~/tmp/bug$ make
> Make
On Thu, 2025-08-28 at 15:50 +0200, Gisle Vanem wrote:
> Paul Smith wrote:
> The parsing should perhaps tolerate a ' ' and a non-exiing
> '(bar)' file then. Since 'lookup_file()' assert's now.
Certainly, any crash is a bug.
> I'm builing the &#x
On Thu, 2025-08-28 at 12:03 +0200, Gisle Vanem wrote:
> With a 'load mk_speak.dll(speak_init)' (no space),
> all is well. Why does it not handle this single
> space?
>
> It seems a 'load' line is parsed similar to a normal include
> file where a ' ' is not legal. Or? IMHO, a space should be
> acce
I did a deeper dive into OS/2 and I suspect that the current "OS/2"
support is actually for ArcaOS not OS/2. I was able to find some
VirtualBox ora images for OS/2, all the way up to Warp 4.5, but ArcaOS
is proprietary and I didn't find any free images available. But they do
have current releases,
On Thu, 2025-08-21 at 08:20 -0700, Collin Funk wrote:
> I don't know much about OS/2, but I remember Gnulib getting some
> occasional patches for it. Here is the last one for example:
Hrm, I spoke too seen; I see that KO Myung-Hun also provided patches
for GNU Make as recently as 2023.
It makes m
Hi all;
As far as I know, OS/2 has been obsolete and out of support for 20+
years.
Does anyone know if there are any OS/2 users still out there? I can't
remember the last time I received a bug report or patch for GNU Make
from anyone on OS/2. While much of the OS/2 support is the same as
either
On Fri, 2025-07-25 at 21:23 +0300, gnu-bug...@mekboy.ru wrote:
> On 2025-07-25, Paul Smith wrote:
> > * Add the --disable-load option to the ./configure command line
>
> --disable-load will disable only this functionality, correct?
> https://www.gnu.org/software/make/manual
On Fri, 2025-07-25 at 20:33 +0300, gnu-bug...@mekboy.ru wrote:
> > I believe this is just a test problem.
> >
> > When the test suite builds the shared libraries it uses the same
> > compiler and compiler flags that were used to build "make". If you
> > have added something like -static to the co
On Fri, 2025-07-25 at 11:51 -0400, Dmitry Goncharov wrote:
> On Fri, Jul 25, 2025 at 11:38 AM wrote:
> > On a static build of make getting 2 failing tests - load and
> > loadapi. Running them manually produces "Dynamic loading not
> > supported" error.
>
> A statically linked executable cannot l
On Fri, 2025-07-25 at 18:00 +0300, gnu-bug...@mekboy.ru wrote:
> On a static build of make getting 2 failing tests - load and loadapi.
> Running them manually produces "Dynamic loading not supported" error.
> Is it running dynlib-related tests on a static build?
I believe this is just a test probl
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
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
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, 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, 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 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'
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
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
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
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
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 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 which are not
>
On Thu, 2025-06-19 at 18:12 +, WaitronCharm via Bug reports and
discussion for GNU make wrote:
> 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' r
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
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
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 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
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
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&
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 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
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 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!
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
1 - 100 of 1553 matches
Mail list logo
