Re: New conditional assignm ent facility

rsbec...@nexbridge.com (27 January 2024 23:45) wrote: > My take on it is that +:= (because of the : ) means that you have to resolve > everything at that point. Surely it could equally mean: fully expand the right-hand side immediately, append to the left-hand variable, preserving its type if

Re: New conditional assignment facility

Paul Smith (27 January 2024 21:32) 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 one makefile and appended to in

Re: Segmentation Fault on Exported Resursively Expanded Variable

MIAOW Miao wrote: if ((*ep)[nl] == '=' && strncmp (*ep, v->name, nl) == 0) Henrik Carlqvist (Tue, 16 Jan 2024 06:59:30 +) wrote: >>> Looking at that line, the rather obvious fix would be to change it to: >>> >>> if (strncmp (*ep, v->name, nl) == 0 && (*ep)[nl] == '=') >>> >>> That way,

Re: Exponential Runtime in make 4.4.1 when export is used

On Wed, Oct 4, 2023 at 6:09 PM Till Backhaus wrote: >> This rather short Makefile shows exponential runtime depending on the number >> of variables. >> VAR_1 ?= $(shell echo 1) Dmitry Goncharov (6 October 2023 17:35) replied, ending: > Prefer simply expanded variables with $(shell). and if you

Re: 4.4.1 breaks recursive invocation with --print-directory [when adding to MAKEFLAGS]

On Feb 28 2023, Satish Balay via Bug reports and discussion for GNU make wrote: >> And the reason we use the order '-j8 ${MAKEFLAGS}' is so that we have the >> following behavior': Andreas Schwab (1 March 2023 10:15) wrote: > You need to write it as MAKEFLAGS="-j1 -${MAKEFLAGS}", so that the

Re: Generating missing depfiles by an automake based makefile

Dmitry Goncharov (10 February 2023 00:24) wrote: > When a depfile is missing (for any reason) the current automake > makefile creates a dummy depfile. This seems misguided. Better to include $(wildcard $(DEPFILES)) instead, so there are no misleading depfiles lying around to cause make to

Re: Old timestamps in the future?

Paul Smith (9 December 2022 16:22) wrote: > That's probably why it works on my system even though I'm at UTC-0500. oh, and: that means you're west of Greenwich, so the epoch is your local time 1969-12-31 19:00, so your 1970-01-01 00:00 is firmly in positive time_t. So you had no chance of

Re: Old timestamps in the future?

On Fri, 2022-12-09 at 15:06 +, Edward Welbourne wrote: >> MS's time_t is indeed 64-bit; and MS's time_t-related POSIX functions >> don't support times before the start of 1970, i.e. negative time_t >> values, so it is eminently plausible MS's time_t is a 64-bit unsigned &g

Re: Old timestamps in the future?

Gisle Vanem (9 December 2022 14:59) wrote: > I have an issue with things like > touch --date="1970-01-01" [snip] > Invoking it a 2nd time, GNU-make warns: >gnumake: Warning: File 'test-file-2' has modification time 1,8e+19 s in > the future >gnumake: Nothing to be done for 'all'. >

Re: Doubts about .WAIT and .NOTPARALLEL (was: GNU Make 4.4 released!)

;  three: one two >>>  one two three: ; @sleep 1; echo $@ >>> >>> Isn't it? On 10/31/22 13:42, Edward Welbourne wrote: >> Only from the point of view of make all; try make three and you'll see >> the difference. >> >> If you make three w

Re: Doubts about .WAIT and .NOTPARALLEL (was: GNU Make 4.4 released!)

On 10/31/22 08:01, Paul Smith wrote: >> * New feature: The .WAIT special target >>    If the .WAIT target appears between two prerequisites of a target, then >>    GNU Make will wait for all of the targets to the left of .WAIT in the list >>    to complete before starting any of the targets to the

Re: [bug #63070] posix_spawn fails to run a child process.

Alejandro Colomar (21 September 2022 11:46) >> If the function is returning 0, there's no error, and errno shouldn't be read > I guess you maybe didn't state it here as obvious, but to me it's not by > reading the conversation: Apart from posix_spawn(3) returning 0 and setting > errno to ENOEXEC,

Re: [bug #62936] Confusing description of chained rules in the manual

Hi Konrad, > Trying to understand a bug in my Makefile, I consulted the manual > section on chained rules > (https://www.gnu.org/software/make/manual/html_node/Chained-Rules.html#Chained-Rules) > and found the following paragraph, which is more confusing than > helpful: >> The first difference

Re: Making makefiles with primarily phony targets more friendly

On Wed, 2022-08-10 at 19:08 +, Katherine Pata wrote: >> Something like --reverse-phony or a variable like .GENUINE or .REAL >> that is mutually exclusive with .PHONY would be really helpful. Paul Smith (11 August 2022 21:49) replied: > Adding such a command-line option is not right, ...

Re: Making makefiles with primarily phony targets more friendly

Jean-Baptiste Poittevin (10 August 2022 22:19) wrote: > By using a lot of PHONY targets, I think you're closing a door to one > make greatest feature : not redoing those things that are already up > to date. While that's entirely true of make's "design-basis" use-case, I am familiar with the

Re: New feature: Post-requisites

On 7/25/22 11:06, Edward Welbourne wrote: >> Also, this new feature smells like it may open up some interesting >> corner-cases in dependency-loop analysis, although I can't think of >> any immediately. Alejandro Colomar (Monday, July 25, 2022 13:54) replied: > The same way

Re: New feature: Post-requisites

On 7/22/22 16:20, Paul Smith wrote: >> So, after all the "normal" goal targets were completed make would >> proceed to run any "extra" goal targets that were added as part of >> the processing of the "normal" goal targets.  Then after the those >> "extra" goal targets were complete, make would

Re: New feature: Post-requisites

th...@vmware.com (22 July 2022 15:28) wrote: > In your example, wouldn't the following accomplish the same thing? > > update-mandb: $(DESTDIR)$(man3dir)/foo.3 $(DESTDIR)$(man3dir)/bar.3 I presume that'd have a rule that runs mandb. And it works as long as you're happy to update all man pages

Re: New feature: Post-requisites

Alejandro Colomar (Friday, July 22, 2022 14:05) > I'd like to suggest a new feature: post-requisites. > > As the word suggests, as pre-requisites are satisfied before a given > target, post-requisites would be satisfied _after_ a given target. and just as a prerequisite can be built at any time

Re: Missing [/usr/local]/var/lib and [/usr/local]/tmp

Alejandro Colomar (Monday, July 18, 2022 14:07) > MacOS seems to be setting TMPDIR (or at least some script run at > startup seems to be setting it in my system), and it's set to something > really weird that I don't trust will exist after reboot. Then I think the way you're using tmpdir

Re: [BUG] inconsistency in $localstatedir and $runstatedir

Hi Alejandro, I think the source of the confusion is that "Should normally be" and how you should write a default value don't match up because it is normal to use non-default values. So systems are commonly set up with localstatedir=/usr/var and runstatedir=/var/run, despite the fact that their

Re: [bug #62706] Restrict second expansion to targets which are being built.

On Tue, Jul 5, 2022 at 5:19 AM Edward Welbourne wrote: >> I would have expected the order to be the exact reverse of the >> order of building: Dmitry Goncharov (5 July 2022 14:29) replied: > i guess, an example will make it more clear. > > $ cat makefile > .SECONDEXP

Re: [bug #62706] Restrict second expansion to targets which are being built.

Dmitry Goncharov (5 July 2022 01:42) wrote (inter alia): > 2. Causes all prerequisites to be second expanded in the same order > they are being built. Really ? I would have expected the order to be the exact reverse of the order of building: src = main.c hdr = lib.h prog: $$(src); $(CC) -o $@

Re: [bug #62228] prerequisite based on input file created during processing not created, but no error

Greg Minshall (30 March 2022 01:27) replied: > thanks very much for the reply. and, for the hints (on better use of > make functions). You're welcome. I do recommend reading the make info pages for the details more often than most developers seem to - most of the tools I've seen that claimed to

Re: [bug #62228] prerequisite based on input file created during processing not created, but no error

Greg Minshall (29 March 2022 06:38) wrote: > hi. sorry. i'm not sure if this is a bug. I'm fairly sure it isn't. > (but, i'm guessing that dependencies are built when the makefile is read, then > not updated?) The assignment of variables happens when the Makefile is read, but there are two

Re: GNU Make bug report: broken dry-run functionality with sub-make invocations

Ambrus Sumegi (21 March 2022 14:22) wrote: > If the invocation is a function, i.e., `$(make,"external_target") | > tee logs/external_task.log` then Make knows exactly where the call to > the sub-make ends without having to parse a shell command. So, when > running with the -n switch, it can simply

Re: Make losing jobserver tokens on Windows

>> I believe that the goal of the Cygwin port is to implement a POSIX >> layer on top of Windows, so I'm assuming that when you compile GNU >> make with Cygwin it uses the POSIX implementation of the jobserver. >> This implementation relies on certain POSIX behaviors of pipes and >> signals and

Re: [PATCH] Fix src/function.c build failure on gcc-12.

Sergei Trofimovich (19 February 2022 00:48) reports: > Upcoming gcc-12 detects possible buffer overflow for 1 byte: [snip] > Unlikely numbers like '-1234567890' including null terminator take 12 > bytes of storage. and that's assuming a 32-bit int; the signed range is from -2,147,483,647 to

Re: Idea of triggering bugs in users' Makefiles

David A. Wheeler (4 February 2022 17:43) wrote: > For example: When running each recipe, enable tracing > to note when files are opened for reading/writing. > If a recipe opens a file for reading (or presence?), and > that file isn't listed as a dependency but SHOULD be, warn about it. > E.g.,

Re: Invalid use of const pointer?

On Sat, 08 Jan 2022 17:29:33 -0500 Paul Smith wrote: >>> It turns out to be innocuous because none of the callers care that >>> the value of the input string is modified if we return a different >>> string, but it's still wrong and should be fixed. Indeed. The compiler is allowed to place a

Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison

On Nov 28 2021, Paul Smith wrote: >> The C standard defines the largest unsigned long long value >> as 18446744073709551615, the largest signed long long value >> as 9223372036854775807, and the smallest signed long long value as - >> 9223372036854775808. So, the definition cannot be wrong in any

Re: [bug #60798] Make does not compile with GCC 11.1.0

Jouke Witteveen (3 December 2021 13:22) wrote: > The next warning I get (GCC11) is a _return-local-addr_ warning in > src/read.c:2534 (find_percent_cached). Maybe GCC doesn't recognize alloca as a > heap allocation? Just guessing; this warning was not obvious to me. alloca() is not a heap

Re: [bug #61594] suggest new $(hash ...) function

> My first counter-argument comes from the "$(shell git hash-object obj)" > suggestion which begs the question: if git, which relies heavily upon SHA-1, > is available, doesn't that mean SHA-1 is also natively available? I'm not > aware of git being restricted in any jurisdictions. Seems

Re: [bug #61594] suggest new $(hash ...) function

rsbec...@nexbridge.com (1 December 2021 13:08) wrote: > I would suggest that adding cryptography to GNU Make would limit its > reach. There are jurisdictions where it is questionable to import > software containing any cryptography. In addition, there are numerous > tools for doing what you want.

Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison

On Sun, Nov 14, 2021 at 8:42 PM Paul Smith wrote: > It's even possible to allow $(compare ,) with no other > arguments and say that if they are equal then it expands to the value, > else it expands to the empty string, to give a very short-circuited > equality statement. I should point out one

Re: [bug #61226] A regression prevents generation of missing included dependency files.

Dmitry Goncharov (17 October 2021 18:33) wrote: > i think, make should not print a warning when a .d file is missing. make > should proceed and create the missing file. However, when .d is present, but > make cannot include it, then make should print an error and stop. Given that I always

Re: Make allows kind of multiple "alias" for the same target

> Here, we have 2 targets: > ../1/../main.o > ../2/../main.o > > In fact, this is the same target/file (taking into account relative > directories). Note that if ../1 or ../2 is a symlink to somewhere else, ../1/.. and ../2/.. aren't the same place. It's the makefile's responsibility to resolve

Re: gmake and ccache conspiring together in creating gremlins

Paul Smith (8 February 2021 20:38) wrote: > There is a loss of debugging information if we make this change: today > make can detect if it was invoked in a way that _should_ expect to > receive a jobserver context, but _didn't_ receive that context. That > is, if make sees that jobserver-auth is

Re: gmake and ccache conspiring together in creating gremlins

Hi Sam, Thanks for a delightfully illuminating analysis. I hope you enjoyed the sleuthing, even if it did cost you a month ! > The TLDR of the above: make reads the job server's file descriptors > from the MAKEFLAGS environment variable, then checks here if they > actually exist. If they don't

Re: [bug #59956] Recipes inside conditionals can break the parser

> Consider the following example: > ifeq (1,0) > test: > @if [ "asd" == "123" ]; then > echo "true" > else > echo "false" > fi > endif > The *else* recipe at line 5 is treated as part of the *ifeq (1,0)* > conditional thus making the next

Re: Form feeds in source code

On Fri, 2020-09-18 at 10:59 -0500, Pete Dietl wrote: >> Why are there so many form feeds in the source? Paul Smith (18 September 2020 18:12) replied: > That was the style that Roland used when the code was written: form > feeds were used inside a source file to separate major functions. > > I

Re: Backslash handling not POSIX-compliant

Ivan Kozlov (28 July 2020 16:18) wrote > The expected behaviour is useful because it allows portably quoting > macros with here-documents, for example: > > sed '$s:\\$::' <<\end; : \\ > > $V\ > > end > should print the literal value of the macro $V that can contain single > quotes and special

Re: [bug #58734] gmake does not check for the existence of a file before complaining it is missing

Jörg Schilling (9 July 2020 16:18) > What I can say to help fixing the problem is that truss(1) shows that > gmake calls stat(2) as a block on a larger list of files at startup > and at that time correctly finds that the file in question does not > exist. gmake caches stat results and makes the

Re: simple assignment of target-specific variables

David Boyce (9 June 2020 15:10_ > I'm not saying this should be considered a bug but it's at least an > "interesting result". Indeed ! I presume the workaround is TGTDATE := $(shell date) $(TARGETS): DATE := $(TGTDATE) at the slightly annoying price of calling the command once even if making

Re: [PATCH 2/2] compare function

On Tue, Jun 9, 2020 at 10:53 AM Edward Welbourne wrote: >> I note that your implementation only supports numeric lhs and rhs. >> Might it be worth falling back, if either of them isn't numeric, to >> doing a strcmp() comparison instead ? Possibly after stripping >>

Re: [PATCH 2/2] compare function

Jouke Witteveen (8 June 2020 22:20) > This is an implementation of a $(compare) function as proposed by > Edward Welbourne. Yay ;^> Looks promising in general. As ever, review consists mostly of criticism, so let me just say I approve of the general plan, befor

Re: Suggestion: Modernization of the include path

Christian Hujer (31 May 2020 15:53) wrote > I suggest that > a) $HOME/.local/include is effectively added to the >include_directories, as if it were inserted in >default_include_directories before /usr/gnu/include. > b) Change function src/read.c/eval_makefile() to loop over >

Re: math expressions (was: Re: Tail call elimination)

Tim Murphy (29 May 2020 01:02) wrote: > Integer maths is important at the language level - it will enable > algorithms that weren't possible before e.g. dividing a list into > equal halves or a for-loop for which we also need a function that > generates a range). Indeed. The only case I can

Re: math expressions (was: Re: Tail call elimination)

Sam Kendall (25 May 2020 18:07) observed: > If you have relational or equality operators, what does the boolean > result look like? If the result is 1 for true and 0 for false, then > you get a bad surprise: $(if $(math =,5,6),yes) expands to yes. If the > answer is some nonempty string for true

Re: math expressions (was: Re: Tail call elimination)

>>> Bit Manipulation: >>> -- >>> * and >>> * or >>> * xor >>> * complement >>> * left shift >>> * right shift >> >> Maybe. I have a hard time coming up with uses for these, other than >> possibly the shift operators (but multiplication/division can be used >> instead). Pete

Dependencies from moc (was Re: Tail call elimination)

Daniel Herring (11 May 2020 21:46) wrote, inter alia, > For example, when a code generator like Qt's moc or uic is run, it > could also generate a rule update that causes Make to compile and link > the results. For reference, Qt6's moc (the Qt project's current dev branch) supports dependency

Re: Incorrect path and shell script error

Loch Brandon (7 May 2020 20:41) wrote: > @if not exist $(OUTPUTDIR)\$(notdir $(OBJDIR)) $(MKDIR) $(OUTPUTDIR)\$(notdir > $(OBJDIR)) > When running without the '@' this is the result: > echo Verifying and building application directory structure... > Verifying and building application directory

Re: GNU make 4.2.93 release candidate available

On 2020-01-11 13:22, Martin Dorey wrote: >> Keeping the new, correct behavior in the .POSIX case, with no >> warning, that might fly, as long as none of Dennis’s myriad failing >> builds use .POSIX. I can imagine Paul finding this third option >> depressing but I think the real value here is in

Re: gmake-4.2.90 regression (segmentation fault in sum_up_to_nul )

On Tue, 2019-09-03 at 04:14 +, Dmitry Goncharov wrote: >> sum_up_to_nul reads 4 bytes starting from the passed string 'p'. 'p' >> can have fewer than 4 bytes. Usually there more allocated space after >> 'p', which prevents this reading from manifesting itself. Usually malloc aligns its

Re: [bug #56892] toxic combination of -include and match-anything rules

David Boyce (14 September 2019 22:28) wrote, on : > I'm not saying this is a bug necessarily but want to submit it for > some sort of resolution. I an into an infinite loop situation > recently. On my advice, in a very old and complex recursive makefile >

Re: Idea: Standard way to negate special targets

David A. Wheeler (11 June 2019 22:25) wrote: > I know of no other use for "!" in prerequisites. Well, it could be a file-name ;^> For example, compare /usr/bin/[ A Unix could implement the shell's ! as an actual command. The make-file to build it would have ! as a target to build. The check rule

Re: Idea: Add .COMMANDCHANGE and .CACHE

On Mon, Jun 10, 2019 at 5:14 PM David A. Wheeler wrote: >>> Using a lot of some_fragment.mk files gets you *closer*, but it's not >>> the same thing. My proposed .COMMANDCHANGE depends on >>> the *expanded* set of commands, not the original commands. >>> That way, if you change a value (say

Re: [bug #55137] $(file …) is executed too early when used in recipe

Paul Smith (16 May 2019 17:37) > The only idea I have for "legitimate real-world use" is something like: > >foo: >do some things >$(DO-MORE) > > where DO-MORE is some boilerplate macro defined elsewhere, that wants > to perform some checking and invoke $(error ...) if

Re: "make -jN" requires mechanical changes to a Makefile

> Howard Chu wrote: > > >> Example with one rule creating 4 files: > > >> > > >> all : copy1 > > >> > > >> copy1: Makefile > > >> install -c -m 644 Makefile copy1 > > >> install -c -m 644 Makefile copy2 > > >> install -c -m 644 Makefile copy3 > > >> install -c -m

Re: Circular dependency with order-only dependencies

Eli Zaretskii (23 January 2019 20:21) > In Emacs, we have a header file that is generated from an certain data > file, but its generation requires an Emacs binary, which runs a Lisp > command to massage the data file into a C header. And the binary > depends on that header because one of the

Re: Idea: --only-make-prerequisites

Dan Jacobson (18 January 2019 08:49) > --only-make-prerequisites is for folks that want to check and get > things ready first, before the President arrives for the button > pushing ceremony. I can see other uses for it ;^> When I'm hacking on code, and intend to hack some more, it's sometimes

Re: no rule to build included makefile but make does not fail

pacalet (4 December 2018 08:38) wrote: > Not sure it is a bug but I think it deserves some attention. Here is an > MCVE: > > ```make > .PHONY: all clean > > all:; > > include a.mk > > a.mk: b > > b: > @touch $@ > @printf '$$(info a.mk included)' > a.mk > > clean: > @rm -f

Re: [bug #55137] $(file …) is executed too early when used in recipe

Marcin Kasperski (30 November 2018 11:59) > I tried using the following snippet: > >OUTPUT/something : > mkdir -p OUTPUT > $(file > $@, something) > > It crashes with > OUTPUT/something: No such file or directory. Stop. > > Moreover, looks like file is executed before

Re: Compacting link-rules

Paul Smith wrote: >>> All the .obj files are missing!? >> >> Oh. $@ is "bin/animation.exe" so $(@F) is "animation.exe" and >> $($(@F)_OBJ) would be "animation.exe_OBJ" but that's not the name of >> your variable, so it expands to the empty string. >> >> Sorry I didn't catch this problem in your

Re: [bug #54529] [Makefile:5: foobar] Segmentation fault

On Aug 21 2018, Mark Galeck wrote: >> Then why does the error say "make: ***" ? Andreas Schwab (21 August 2018 09:42) replied: > Because it's the messenger. Indeed. It remains that the message is apt to confuse a user. If the message included (at least the name of) the command that failed,

Re: use of math.h / libmath discouraged?

On Wed, 2018-07-25 at 14:25 -0600, Brian Vandenberg wrote: >> # note: the space before the word TEXT is helpful for readability but causes >> a problem >> $(info $(call F1, TEXT)) Paul Smith (28 July 2018 14:48) replied: > To me this seems like a bug. In GNU make generally the rule is >

Re: Linux kernel 2.6.26, make 4.1, menuconfig: no rule

Brenton Chapin (7 June 2018 18:30) wrote > Tried to configure Linux kernel 2.6.26 on Lubuntu 18.04 with make 4.1 and gcc > 7.3. > "make menuconfig" gives "No rule to make target menuconfig". > > With make 3.8 (Lubuntu 12.10), menuconfig works. > With kernel 2.6.32 and make 4.1, menuconfig works.

Re: Pattern matching for static pattern rules

Alex Dehnert (22 May 2018 00:03) > I was running into some behavior that surprised me when using static > pattern rules with files in a subdirectory. [snip] > With (implicit) pattern rules, "When the target pattern does not contain a > slash (and it usually does not), directory names in the file

Re: posix_spawn() instead of fork()?

Barath Aron (13 March 2018 21:47) > I'd like to build projects on a system that lacks fork() and vfork() > support, but has posix_spawn(). Would you implement an alternate version > using posix_spawn() to spawn child processes? You might get lucky, but the maintainer probably has many other

Re: Add .ALL_WARNINGS_FATAL special target

Dan Jacobson (29 December 2017 03:41) [snip] > Therefore please add a new > '.ALL_WARNINGS_FATAL' > or something (that we error prone careless > programmers can use, just like we put > use warnings FATAL => q(all); > in all perl files we write today,) > or make it the default, and instead add a >

Re: mention if a=b make = make a=b

Dan Jacobson (20 November 2017 23:50) > (info "(make) Environment") should mention how equivalent > $ a=b make #and > $ make a=b > are to each other. > See also http://debbugs.gnu.org/29270 They're not quite equivalent, although an example like the one you give may be a good one for the

Re: Target-specific variable in subdirectory problem

Benjamin Cama (2 August 2017 12:19) > I may be doing something wrong, but the following Makefile gives me > strange results: the target-specific variable does not apply when used > for a target in a subdirectory. > >test-%: FOO = BAR >test-%: >echo $(FOO) > > E.g.:

Re: A Severe Problem with Make

Iman Moosaie (19 July 2017 19:19) > I use Ubuntu Linux on my system. I have downloaded and tried to > install the make-4.2.1 package but when I execute the 'make' command > (after the package is configured) I encounter a problem and I don't > know how to resolve. can you help me? > > I have put

Re: [bug #51495] Notice when a rule changed, so target needs rebuilding

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 changed it is also > possible to split the Makefile up into several

Re: [bug #51434] Document that variables are treated differently in prerequisite lists and recipes

> VARS=a.c b.c > > p: $(VARS) > echo i am using $(VARS) to build > echo $(VARS) > p > > VARS=x.c y.c > > Here $(VARS) in the prerequisite list is expanded when make reads that > line of the file (to "a.c b.c") but the $(VARS) in the recipe on the > next line is expanded to its value

Re: [bug #51311] Checking search retries for implicit make rules

Mike Gran (25 June 2017 22:54) > The '%' (the stem) in a pattern rule doesn't, if I recall correctly, > match a null string. It needs to match at least a single character, > so building MOTD.log won't work. At the risk of stating the obvious, note that there is a trivial work-around for this -

Re: [bug #51269] Reusing data from targets for prerequisites

Markus Elfring (20 June 2017 11:43) > I got another software development concern for such an use case. > > * Can it eventually happen that dependencies will not be resolved if > target names do not contain the percent character? I can't remember, but a simple experiment should answer that ! >

Re: [bug #51269] Reusing data from targets for prerequisites

Markus Elfring (19 June 2017 19:34): > The documentation contains the following information: > “… > It’s very important that you recognize the limited scope in which automatic > variable values are available: they only have values within the recipe. > …” > > How are the chances to adjust this

Re: Are prerequisites made in deterministic order when parallelism is disabled?

Brett Stahlman (13 June 2017 17:33) > I don't see anything in the Make docs that guarantees prerequisites > will be processed in left to right order. Opinions on the web seems to > be split into 2 camps: > > 1. Make always builds dependencies in left to right order, but a >well-designed

Re: Q: On Windows why not ignore CRLF?

Paul Smith (31 May 2017 19:48:57 -0400) >> > #if !defined(WINDOWS32) && !defined(__MSDOS__) && !defined(__EMX__) >> > /* Check to see if the line was really ended with CRLF; if so >> > ignore >> >the CR. */ >> > if ((p - start) > 1 && p[-2] == '\r') >> > {

Re: GNU Make 4.1 carrying on after -f missingfile.mak

Jonny Grant (24 May 2017 12:27) > In that successful case, would the "No such file or directory" message > not be visible? My guess is that it would be displayed, by the initial run of make; but then make would re-invoke itself and do its job. As long as the rule to make the missing make-file

Re: GNU Make 4.1 carrying on after -f missingfile.mak

Jonny Grant (24 May 2017 09:40) > $ make -f missingfile.mak > make: missingfile.mak: No such file or directory > make: *** No rule to make target 'missingfile.mak'. Stop. > > Shouldn't Make exit after the missing file? > > Make appears to be carrying on, and then treating the makefile as a target.

Re: [bug #50823] MAKEFILE_LIST contains wrong file name if file name contains dollar character

> To reproduce: > > $ echo -e 'all:\n\techo $(value MAKEFILE_LIST)' > /tmp/foo\$bar.mk > $ ./make -f '/tmp/foo$bar.mk' > echo /tmp/fooar.mk > /tmp/fooar.mk > > I think this is inconsistent and contradicts the documentation, which states > "MAKEFILE_LIST Contains the name of each makefile that is

Re: [bug #50790] Some kind of memory corruption in error messages with gcc-6.3.0 -flto=4

Jan Ziak (12 April 2017 20:07) > Is this a make-4.2.1 bug, or a gcc-6.3.0 bug? The line numbers in the garbled > error messages, in this case 79 and 84, are correct. Given its sensitivity to the specific flags passed to gcc, it's natural to suppose it's a gcc bug. You can test by running gcc

Re: errors in "make"

wu (7 March 2017 08:55): > the software reports the following errors: > > ... relocation ... against `.rodata' can not be used when making a shared > object; recompile with -fPIC I recommend you do as it says; change your CFLAGS or CXXFLAGS to use -fPIC (replacing -fpic,

Re: [bug #50062] Variable needed to check that Makefile is run by GNU make?

> If you really need some features only supported by GNU Make, why not > rename this makefile to "GNUmakfile"? ... which, furthermore, ensures that - if the make-file is picked up by some other make that thinks it knows what to do with a GNU make-file - the reader is primed with the knowledge

Re: [bug #50062] Variable needed to check that Makefile is run by GNU make?

> When one wants to check that it is really GNU make that is run for a > given Makefile The only valid use case I can think of for this is where some particular feature of GNU make is needed. Generally, it is better to test *that feature* rather than the version of make in use. If another

Re: [bug #49681] Make fails to glob lib/*.{o,a}

anonymous reported: > This is a regression from GNU make 4.0. The make target > > clean: > rm lib/*.{o,a} > > fails to remove files lib/foo.o, lib/bar.o, and lib/libfoobar.a because > lib/*.{o,a} does not glob lib/*.o and lib/*.a, as is its intention. This is a rule, which make hands

Re: [PATCH] Improve “missing separator” error when reading spaces

Michael Stapelberg's patch: diff --git a/read.c b/read.c index b870aa8..3c67e55 100644 --- a/read.c +++ b/read.c @@ -1122,6 +1122,8 @@ eval (struct ebuffer *ebuf, int set_default) one of the most common bugs found in makefiles... */ if (cmd_prefix == '\t' && strneq

Re: exported vs command line variables

On Fri, 2016-09-23 at 13:24 +, Edward Welbourne wrote: >> This does seem like an unsound choice, for the reasons David gave, Paul Smith replied: > Perhaps but as discussed, it's been that way in GNU make (and other > versions of make) forever and is required by the POSIX standard.

Re: exported vs command line variables

David Boyce observed: > I was unpleasantly surprised to learn while following this discussion > that "Except by explicit request, make exports a variable only if it > is either defined in the environment initially _or set on the command > line_". ... and I was surprised to find (by experiment

Re: Bug/Typo in make man Page

Pooya Taherkhani wrote: >> To prepare to use make, you must write a file called the makefile >> that describes the relationships among files in your program, and the >> states the commands for updating each file. > I think "..., and the states the commands for ..." should be "..., and > states

Re: reverse dependency order?

> It might be interesting to have a make flag that would reverse the order > in which dependencies are considered, ... or indeed randomise the order, so that repeated testing would routinely catch any un-noticed dependencies. Does anything actually specify that order of prerequisites in a rule

Re: [bug #46242] Race condition when input file is updated while compiling

> There's an inherent race condition in the way "make" handles timestamps. If > you save a newer version of a file while make is running and is just compiling > that input file, the change won't be picked up by subsequent runs of "make", > and you'll be left with an out-of-date binary. The

Re: Make: Unexpected Behavior with Dependencies and include Statement

> I was thinking to build the objects but not the dependencies. We do a lot > of one-time only builds, where we don't need dependencies at all. In that case, leave out the include of any .d whose .o doesn't exist; you fatuously know you need to build the .o, so you don't need to know its

Re: make -jN runs some rules more than once

>> a.gz b.gz: >> touch a >> gzip a >> touch b >> gzip b Paule explained (in detail) > multiple explicit targets are just a shorthand way of writing multiple rules, ... and if you actually want to do two things at the same time, you can do it, via a phony

Re: Rebuilding archives

> My problem is that Fedora have choosen to ship a broken version of > "ar" that always sets the timestamp of all archive members to 1970-01-01 > unless one invokes it with the U flag. For the sake of anyone else curious about what that means, here's what man ar told me when I looked up the

Re: [patch] Guile conditional

ifeq ($(shell if [ -f /my/file ] ; then echo 0; else echo 1; fi), 0) Why not: ifneq ($(wildcard /my/file),) which tests existence just as well. Of course, it does also match if /my/file is a directory or other non-file, but it's almost always sufficient, unless there's some actual

Re: [bug #45275] 4.0+ core dumps with long .PHONY targets via variables

4. Running under gdb I was able to get a stack trace showing the eventual seg fault occurring in xcalloc(). The trace is below. This almost certainly means that, before this point, something over-ran the end of a memory buffer and trampled malloc's data structures. So the first line of enquiry

Re: new flag to show executing shell command

I am a new beginner of gnu Make. in some cases, I fell that it will help if Make can print the executing shell command even suppressed, for example, to identify problem more easy. Since it seems that Make doesn't have this flag, I tried to change code. the code diff is in below and happy to

  1   2   >