On Thu, Dec 10, 2020 at 1:33 PM Paul Smith wrote:
> On Thu, 2020-12-10 at 18:19 +, DUDZIAK Krzysztof wrote:
> > Operators ‘=’ ‘:=’ ‘::=’ seem to have two dimensions these control
> > things expansion recursiveness (simple vs. recursive expansion)
> > expansion time (immediate vs. deferred)
>
Follow-up Comment #11, bug #59154 (project make):
[comment #9 comment #9:]
> I don't think this would require Make to parse double quotes.
>
> My guess is it would mean passing along expanded variables to the shell
without parsing the variable contents for newlines.
>
> If I have time, maybe I'l
Follow-up Comment #8, bug #59154 (project make):
[comment #7 comment #7:]
> If the string isn't quoted, the first newline would naturally signal a new
command to the shell, wouldn't it?
>
> Got an example of a real-world Makefile that would break?
Nope. But that doesn't mean there isn't one.
Th
Follow-up Comment #6, bug #59154 (project make):
[comment #5 comment #5:]
> (To be precise, the line
>echo "${BLAH}"
> works in all the shells I've tested, and in BSD Make, but not GNU Make. If
BSD Make can get this right, seems like gnu make should be able to, too.)
This could break a t
Evidently, assignments to pattern-specific simple variables don't build on
top of each other, but in fact only the last one wins. So, for instance:
CFLAGS := -Wall
%.o: CFLAGS := $(CFLAGS) -march=haswell
%.o: CFLAGS := $(CFLAGS) -Werror
foo.o: foo.c
$(CC) $(CFLAGS) -c $< -o $@
drops th
>
> On 2018-05-21 at 07:46, Kyle Rose wrote:
> > $(call x) rebinds the positional parameters. $x and $(x) do not. This
> > distinction is used to break macro logic into smaller pieces in which $1
> et
> > al. still refer to the positional parameters from the top-level
$(call x) rebinds the positional parameters. $x and $(x) do not. This
distinction is used to break macro logic into smaller pieces in which $1 et
al. still refer to the positional parameters from the top-level macro
instead of being rebound to the empty string.
Kyle
On Mon, May 21, 2018, 4:11 AM
On Thu, Aug 3, 2017 at 12:53 PM, Martin Dorey wrote:
> "It’s very important that you recognize the limited scope in which automatic
> variable values are available: they only have values within the recipe. In
> particular, you cannot use them anywhere within the target list of a rule;
> they ha
On Aug 3, 2017 9:00 AM, "Benjamin Cama" wrote:
Anyway, it seems that a global variable would solve my problem, and
indeed it looks a bit more right this way: I can still get the stem in
my recipe (with $*), and everything works as expected. It's just that
the global namespace is “polluted” by thi
Paul's interpretation appears to be the same as mine, and seems like
the only straightforward interpretation of the OP's message. If that's
the case (and Benjamin can tell us if it is not), I believe his
message from 3:16 ET entirely explains the difference in behavior
between test-% used in patter
On Wed, Aug 2, 2017 at 3:03 PM, Sven C. Dack wrote:
> Hello,
>
> try it with the following rules:
>
> test-%: $(eval FOO = BAR)
> test-%:
> echo $(FOO)
FOO is a global variable in this case. Not sure what you're trying to
demonstrate here.
Kyle
__
this too. It might still be
> preferable for it to be handled entirely by the tool, but it can be done at
> the makefile level.
>
> On Tue, Jul 18, 2017 at 7:07 AM, Kyle Rose wrote:
>
>> On Tue, Jul 18, 2017 at 4:00 PM, Edward Welbourne > > wrote:
>>
>>> Hen
On Tue, Jul 18, 2017 at 4:00 PM, Edward Welbourne
wrote:
> Henrik Carlqvist (18 July 2017 15:46)
> > The quick and easy way to accomplish this today is of course to also
> > add the Makefile to the prerequisites of targets. If you don't want
> > every target to be rebuilt when only one rule has c
The right answer is always to write your makefiles so the rules execute in
the required order whether run in parallel or not. Relying on whichever
arbitrary ordering GNU make employs, even if that behavior is stable
(either historically or by design), is likely to result in sadness at some
point, s
On Thu, Mar 16, 2017 at 11:59 AM, Daniel Herring
wrote:
> Hi Paul,
>
> Have you considered using the pattern of using a socket for signal
> handling? Then the signal handler writes a byte or closes the socket. The
> other end of the socket detects this using select() or equivalent. Can be a
> un
Follow-up Comment #6, bug #42125 (project make):
I think maybe the naming is unfortunately confusing. A static pattern rule is
best regarded as a form of shorthand. I think many folks read the semantics of
search into the word "pattern", when in this case it's just substitution.
I'd be much more
On Thu, Oct 6, 2016 at 12:01 PM, Martin Dorey wrote:
> I can reproduce it too:
>
>
>
> martind@swiftboat:~/playpen/kyle-rose$ rm -f target*;
> ~/download/make-git/make
>
> touch target1
>
> touch target2
>
> touch target3
>
> touch target4
>
> t
On Thu, Oct 6, 2016 at 12:03 PM, Eli Zaretskii wrote:
> It works as you'd expect for me even on MS-Windows, as it did for Paul
> on GNU/Linux, so I'm curious what kind of filesystem do you have
> there. (I think this issue has much more to do with the type of
> filesystem than with the OS.)
>
T
On Thu, Oct 6, 2016 at 12:06 PM, Paul Smith wrote:
> > 4.2.1 definitely broken, at least on my system.
>
> It works on my system. I've tried it multiple times. I'm using Ubuntu
> GNOME 16.04.1, with GNU libc 2.23, on an ext4 filesystem.
>
Broken here on on Debian using the Linux kernel with gl
On Thu, Oct 6, 2016 at 11:38 AM, Paul Smith wrote:
> You should include the version of GNU make that you're using; my
> version works as expected:
>
> $ make --version
> GNU Make 4.2.1
>
Funny you should mention that:
$ make --version
GNU Make 4.2.1
Built for i686-pc-linux-gnu
Copyright (C) 198
all: $(addprefix target,1 2 3 4 5 6 7 8 9 10)
@echo glob: $(wildcard target*)
target%:
touch $@
To wit:
$ make
touch target1
touch target2
touch target3
touch target4
touch target5
touch target6
touch target7
touch target8
touch target9
touch target10
glob:
$ make
glob: target10 target3
21 matches
Mail list logo
