[bug #35323] When the environment is modified with export or undefine, $(shell ...) still inherits the original environment

URL: http://savannah.gnu.org/bugs/?35323 Summary: When the environment is modified with export or undefine, $(shell ...) still inherits the original environment Project: make Submitted by: phantal Submitted on: Tue 17 Jan 2012 09:00:02

[bug #35336] Altering MAKEFLAGS doesn't correctly alter the behavior of make

URL: http://savannah.gnu.org/bugs/?35336 Summary: Altering MAKEFLAGS doesn't correctly alter the behavior of make Project: make Submitted by: phantal Submitted on: Fri 20 Jan 2012 08:01:03 AM GMT Severity: 3 - Normal

[bug #36486] Overrides and append to pattern specific variables

Follow-up Comment #1, bug #36486 (project make): Similar to the OP's bug: override ASDF := global A: ASDF += A1 A: @echo ${@}: ${ASDF} Running make causes it to print: A: global A1 ___ Reply to this item at:

[bug #36844] Private variables can still leak to dependencies if += is used

Follow-up Comment #1, bug #36844 (project make): In the original submission, I left out a couple of lines in the section exemplifying the problem; the variables 'T1' and 'T2' are there strictly for the sake of making it convenient to test this without having to modify the makefile for each test.

re: bug #36844

If anyone has a moment to take a look at bug 36844, I would appreciate some feedback as to whether this is a valid bug or not. I've been told the workaround I came up with is acceptable for now if it's definitely a bug in gmake, but if it's not a legitimate bug then I need to come up with a

[bug #36844] Private variables can still leak to dependencies if += is used

Follow-up Comment #4, bug #36844 (project make): I agree. This is a duplicate of the first bug. ___ Reply to this item at: http://savannah.gnu.org/bugs/?36844 ___ Message sent via/by

[bug #36844] Private variables can still leak to dependencies if += is used

Follow-up Comment #5, bug #36844 (project make): Is there a schedule for the planned release of 3.82? ___ Reply to this item at: http://savannah.gnu.org/bugs/?36844 ___ Message sent via/by

[bug #36844] Private variables can still leak to dependencies if += is used

Follow-up Comment #6, bug #36844 (project make): 3.83, that is. ___ Reply to this item at: http://savannah.gnu.org/bugs/?36844 ___ Message sent via/by Savannah http://savannah.gnu.org/

[bug #38420] $(realpath ...) doesn't recover from signals

URL: http://savannah.gnu.org/bugs/?38420 Summary: $(realpath ...) doesn't recover from signals Project: make Submitted by: phantal Submitted on: Tue 26 Feb 2013 10:21:44 PM GMT Severity: 3 - Normal Item

[bug #38420] $(realpath ...) doesn't recover from signals

Follow-up Comment #1, bug #38420 (project make): Also, need to include errno.h. ___ Reply to this item at: http://savannah.gnu.org/bugs/?38420 ___ Message sent via/by Savannah

[bug #38420] $(realpath ...) doesn't recover from signals

Follow-up Comment #3, bug #38420 (project make): Paul, You're spot on. It is Solaris / NFS 3. In the interim I'm using a build with the fix I suggested. Do you know of a workaround for this that wouldn't require deploying a modified version of make?

[bug #38432] Optional parameter to tag all output lines with unique text to improve logging capabilities

URL: http://savannah.gnu.org/bugs/?38432 Summary: Optional parameter to tag all output lines with unique text to improve logging capabilities Project: make Submitted by: phantal Submitted on: Wed 27 Feb 2013 07:13:05 PM GMT

[bug #38420] $(realpath ...) doesn't recover from signals

Follow-up Comment #5, bug #38420 (project make): Paul, I'm using `realpath` for defensive coding purposes. I'm using a pattern rule of the form: %.so : $(if $(realpath $(filter %.o,${^})),,$(warning No dependencies specified for ${@})@false) recipe goes here ... where the dependencies

Re: [bug #38420] $(realpath ...) doesn't recover from signals

On Wed, Feb 27, 2013 at 11:36 AM, Philip Guenther guent...@gmail.com wrote: On Wed, Feb 27, 2013 at 9:44 AM, Brian Vandenberg invalid.nore...@gnu.org wrote: Follow-up Comment #3, bug #38420 (project make): You're spot on. It is Solaris / NFS 3. In the interim I'm using a build

[bug #44442] plugin interface enhancements

Follow-up Comment #1, bug #2 (project make): re: the example I just uploaded ... my comment was poorly worded. I re-wrote it to look more like the functions in function.c in the make source -- though I wasn't sure what to use in place of gmk_expand. Another useful one would be a variant of

[bug #44464] gmk_add_function retains ptr to name it's given

Follow-up Comment #1, bug #44464 (project make): In case someone thinks that's a silly thing to want to do, I thought I'd post another example: {{{ /*...*/ extern C int blah_gmk_setup( const gmk_floc* floc ) { for( some_map_t::iterator iter : some_map ) { gmk_add_function(

[bug #44464] gmk_add_function retains ptr to name it's given

URL: http://savannah.gnu.org/bugs/?44464 Summary: gmk_add_function retains ptr to name it's given Project: make Submitted by: phantal Submitted on: Sat 07 Mar 2015 09:45:42 AM GMT Severity: 3 - Normal Item

[bug #44464] gmk_add_function retains ptr to name it's given

Follow-up Comment #2, bug #44464 (project make): What I'm using it for is a way to create a number of functions that can be used like $(if) but they test a specific condition and only evaluate either the true or false part, not both. For example: {{{ $(setstate if_something, $(ifdef

[bug #46582] Expose some mechanism for getting access to a copy of "reading_file"

URL: Summary: Expose some mechanism for getting access to a copy of "reading_file" Project: make Submitted by: phantal Submitted on: Tue 01 Dec 2015 08:04:46 PM GMT Severity: 3 -

[bug #46583] plugin: command-line option for loading plugin libraries

URL: Summary: plugin: command-line option for loading plugin libraries Project: make Submitted by: phantal Submitted on: Tue 01 Dec 2015 08:15:18 PM GMT Severity: 3 - Normal

[bug #46443] $(warning message) line number incorrect if after TAB

Follow-up Comment #3, bug #46443 (project make): A minor correction to my last comment: The change in job.c around line 2099 should be to add the line: child->file->cmds->fileinfo.offset = child->command_line - 1; With the changes I've outlined I see correct line numbers with this makefile:

[bug #46443] $(warning message) line number incorrect if after TAB

Follow-up Comment #2, bug #46443 (project make): I started to go down the path of changing job_next_command and new_job where allocated_variable_expand_for_file gets called, but quickly came to the conclusion that altering file->fileinfo.lineno wasn't the way to go at all. The simplest approach

[bug #46443] $(warning message) line number incorrect if after TAB

Follow-up Comment #4, bug #46443 (project make): I've just finished testing -n, -d, -p, --trace, and --warn-undefined-variables; they all seem to report correct line numbers. ___ Reply to this item at:

[bug #46585] variables being auto-exported to the environment if it was set in the environment

URL: Summary: variables being auto-exported to the environment if it was set in the environment Project: make Submitted by: phantal Submitted on: Wed 02 Dec 2015 02:06:52 AM GMT

[bug #46400] *** missing separator, when expanding empty define'd variable

Follow-up Comment #1, bug #46400 (project make): This happens with macros as well: make_target = $(call ${0}_,$(strip ${1}),$(strip ${2})) define make_target_ = $(eval ${1}.cc := $(wildcard *.cc)) $(eval ${1}.o := ${${1}.cc:%.cc=%.o}) $(eval ${1} : ${${1}.o}) endef # this will cause the same

[bug #46580] plugin: macro functions cannot be called with zero parameters

URL: Summary: plugin: macro functions cannot be called with zero parameters Project: make Submitted by: phantal Submitted on: Tue 01 Dec 2015 07:54:57 PM GMT Severity: 3 - Normal

[bug #46581] load macro: warning: undefined variable '.LOADED'

URL: Summary: load macro: warning: undefined variable '.LOADED' Project: make Submitted by: phantal Submitted on: Tue 01 Dec 2015 07:58:44 PM GMT Severity: 3 - Normal

Re: Make, MAKE_TERMOUT, color escape sequences, TTYs, and PTYs

On the one hand I can see some value in this effort, but it seems simpler for build maintainers to overtly request colorized output if that's what they want. If the tools start generating escape sequences for other than colorizing text it may not be sufficient, but in general it seems like a

[bug #46582] Expose some mechanism for getting access to a copy of "reading_file"

Follow-up Comment #1, bug #46582 (project make): The first sentence in that was worded poorly; there's no obvious/apparent way to use it too determine the current makefile/line. Clearly it could be used to pass in src:line pairs for gmake APIs that are exposed / take one of these structs.

Re: Order of expansion of recipe lines

My apologies if this ends up being a double-post. I've gotten used to the fact that expansion occurs before recipe invocation, but I'll lay out some of my thoughts on this. Currently, expansion occurs in the parent process before it fork()s. One of the things I was doing in the build

Re: Next release of GNU make coming soon

> > I've been thinking about updating the autotools prerequisites in the GNU > make build system to newer versions; that would include autoconf, > automake, and gettext. > > I'm most interested in gettext as the version we're using now (0.18.4) > has some old/deprecated autoconf m4 macros that

[bug #47409] API support for accessing build internals

URL: Summary: API support for accessing build internals Project: make Submitted by: phantal Submitted on: Mon 14 Mar 2016 05:33:25 PM GMT Severity: 3 - Normal Item

Re: Next release of GNU make coming soon

> > If you have things you'd like to see addressed that you haven't gotten > around to sending or adding to Savannah, now would be the time to do > that. I would appreciate it if the patch I submitted for bug 46443 could get evaluated for inclusion. -brian

Re: Order of expansion of recipe lines

> > As you say, done simply this would be a major backward-incompatibility > and very complicated to explain as well. To avoid the backward > -incompatibility we'd need to do some kind of semi-evaluation that only > processed functions we know (a) might have side-effects, and (b) will > expand to

[bug #46995] Within 'define' newline is treated as non whitespace

Follow-up Comment #1, bug #46995 (project make): I don't know whether they'll want to fix this, but this is the pattern I use for situations like that: define SOMETHING = $(foreach variable, list of values , expression ) endef I would prefer leading commas as in: define SOMETHING =

[bug #47409] API support for accessing build internals

Follow-up Comment #1, bug #47409 (project make): w/regard to build introspection: this could be useful for doing something like the following. Admittedly it's a contrived example, but I've had ideas along these lines (but less contrived) that it would help with: TARGETS := ... some stuff here

[bug #47421] Add support for doing plugin macro overloading

Follow-up Comment #1, bug #47421 (project make): I forgot to say this w/regard to the code snippets: the spots where I'm registering the same macro name is what I _want_ to be able to do, whereas the makefile snippet is workable albeit with a single function with a fair amount of conditional

[bug #47421] Add support for doing plugin macro overloading

URL: Summary: Add support for doing plugin macro overloading Project: make Submitted by: phantal Submitted on: Tue 15 Mar 2016 04:30:57 PM GMT Severity: 3 - Normal Item

[bug #47419] Make it possible to call zero-argument plugin macros without awkward syntax

URL: Summary: Make it possible to call zero-argument plugin macros without awkward syntax Project: make Submitted by: phantal Submitted on: Tue 15 Mar 2016 03:47:58 PM GMT Severity: 3

Re: [bug #46995] Within 'define' newline is treated as non whitespace

> > So I understand that the problem actually is that foreach adds whitespace > into > variable name. > > $(foreach var , $(LIST), do something with $(var )) > > while in contrast for example 'call' knows to strip whitespace from a var > name > so this: > > $(call var ,$(ARG)) > will actually

[bug #46995] Within 'define' newline is treated as non whitespace

Follow-up Comment #3, bug #46995 (project make): My apologies for the double-post. I responded to the mailing list and that didn't add it to the bug history. > So I understand that the problem actually is that > foreach adds whitespace into variable name. > > $(foreach var , $(LIST), do

[bug #47624] Suppress unnecessary warning for "include XXX" when we know how to build XXX

Follow-up Comment #2, bug #47624 (project make): I would suggest one small change: instead of making the message go away entirely, change it to reflect the full situation: a) No such file or directory, no path to rebuild. Stopping. b) No such file or directory, rebuilding from target (...) c)

[bug #46580] plugin: macro functions cannot be called with zero parameters

Follow-up Comment #5, bug #46580 (project make): Oops, you're right; I forgot I'd posted this bug when I posted that one. ___ Reply to this item at: ___

[bug #47913] newlines lost with $(foreach)

Follow-up Comment #4, bug #47913 (project make): You could get the same behavior as before as long as the dependency list is exactly 1 file: define ASDF = Filee.cpp:File.h Other.cpp:Other.h endef SPACE:= SPACE:=${SPACE} ${SPACE} here = here $(foreach x,${ASDF},$(subst ${SPACE},:,$(foreach

[bug #47913] newlines lost with $(foreach)

Follow-up Comment #1, bug #47913 (project make): This is probably related to the fix for bug 46995. I haven't looked at the fix for that bug but I had expected the fix would be to strip the 1st argument in $(foreach) as opposed to stripping all the arguments.

Re: reverse dependency order?

You'll only catch these problems randomly with the solution outlined below but it should help flush them out. I think it would be unwise to leave this in as a permanent change to your build, but as a one-off hack for automatically discovering dependency issues it's reasonable. If the extra time

[bug #10593] $(shell) doesn't honor export but this is undocumented?

Follow-up Comment #3, bug #10593 (project make): Or perhaps the better named: $(setenv TEST,something else) ___ Reply to this item at: ___ Message

[bug #10593] $(shell) doesn't honor export but this is undocumented?

Follow-up Comment #2, bug #10593 (project make): This has the potential to create a backward compatibility problem if it were fixed. Currently someone could take advantage of the fact that "export" does not export to $(shell) environments and "fixing" this would alter that behavior. As an

Re: GNU make release candidate 4.1.90 available for download

as the extra member). I feel that there's no need to have the > offset member visible through the loadable object API. > On Mon, May 2, 2016 at 12:32 PM, Paul Smith <psm...@gnu.org> wrote: > On Mon, 2016-05-02 at 12:26 -0600, Brian Vandenberg wrote: > > When I made the patch for th

Re: Parallel builds across makefiles

I haven't seen similar issues but I have a hypothesis: make is single-threaded and therefore it consumes output from jobs in the same thread it uses to reap/spawn new jobs. If make is spending a large enough amount of time consuming output then this will impacts the rate at which it can

Re: Defining new targets with eval during secondary expansion?

> > This is a bit nicer but there's still some duplication. What I'd like to do > is replace the argument on the right hand side with $(dir $@). With > secondary > expansion enabled I could write something like this: > > mktargetdir = $(eval $(call mkdir_template,$(dir $@))) $(dir $@) > >

Re: Defining new targets with eval during secondary expansion?

> > ASDF = $(foreach x, ${1}, $(eval $(call ${0}_, ${1}, $(dirname ${1} > ${1} > define ASDF_ = > ${1} :| ${2} > ${2} : ; mkdir -p ${@} > endef > > $(call build/foo/bar/baz/mytarget) : other dependencies for mytarget > That last line should've read: $(call ASDF, build/foo/bar/baz/mytarget)

Re: [bug #50372] gmk_floc missing offset member

Originally there was only one struct that didn't have an offset member. I submitted a patch that added offset and made various code changes to ensure its use so warnings/error messages could correctly calculate the line number. Although I didn't like that "offset" was left out of the

Re: use of math.h / libmath discouraged?

> > Wouldn't profiling information help? > See details and link to code with 3.81 that does this at: > Yes, it would. I was unaware of that issue. It looks as though that feature never made it in [unfortunately]. If it were added, was present in a default build and there were a way to

Re: use of math.h / libmath discouraged?

> > However, I'm not sure that this function is sufficiently generic to be > added as a built-in function. Can you provide use-cases for it? > I suppose that depends on the definition of "sufficiently generic". The two definitions that come to mind: 1. Useful for many people who do build

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

. -brian On Sat, Aug 18, 2018 at 2:52 PM, Brian Vandenberg wrote: >> OK, the only system for which this bugs actually shows up, is work build >> server, and unfortunately, the IT guy does not know where the cores are, and >> gdb is not working. Let me talk to him about fixing gdb a

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

> OK, the only system for which this bugs actually shows up, is work build > server, and unfortunately, the IT guy does not know where the cores are, and > gdb is not working. Let me talk to him about fixing gdb and I will get back > to you what I find from it. This may depend on the

use of math.h / libmath discouraged?

Greetings, In a plugin I wrote I created a function with the following form / function: $ cat makefile ASDF := something $(timeit 100, ${ASDF}) $ make makefile:2 Time taken: mean: 232, stdev: 81.719765 make: *** No targets. Stop. ... where "timeit" is implemented using the online

Re: [bug #53201] Target runs incorrect command when shebang line exceeds kernel limit

I cannot remark on pip specifically, but some script interpreters seem to ignore the shebang line if the script is passed as an argument: $ cat /tmp/blah.sh #!/bin/bash printf( "%s:%d\n", __FILE__, __LINE__ ); $ /tmp/blah.sh /tmp/blah.sh: line 2: syntax error near unexpected token `"%s:%d\n",'

Re: [bug #54727] foreach variable is not visible for a target specific variable definition in a recipe

On Thu, Oct 4, 2018 at 7:53 AM Michael Builov wrote: > > Follow-up Comment #3, bug #54727 (project make): > > It also possible to step on this "foreach + eval" bug not in a recipe. Agreed, I reproduced with the following: $ cat -n makefile 1 .RECIPEPREFIX := > 2 f:=g 3 asdf=$(foreach

Re: [bug #54675] avoid redundant recipe warning for identical recipes

On the one hand that might seem convenient, but that would open the door to mistakes being introduced that you would undoubtedly want to avoid, eg: * accidental copy/paste * someone else adding conflicting recipes (disabling the warning would make this unnoticeable) I handled 'mkdir' stuff by

Re: Question about `wildcard` value caching

Minimal example: $ cat makefile $(shell rm -rf /tmp/blah) $(shell mkdir -p /tmp/blah) ASDF = $(info $1 $(wildcard /tmp/blah/*) $(if ${BLAH},$(info before $(wildcard /tmp/blah/*))) $(shell touch /tmp/blah/{a,b,c}.txt) $(info after $(wildcard /tmp/blah/*.txt)) $ make --version GNU Make 4.1

Re: [bug #55243] Request for a way to indicate that the same recipe execution produces several targets

I usually instruct my co-workers to avoid making recipes along those lines as I consider it to be a form of painting yourself into a corner, though there are times where it's unavoidable. In the build I maintain it used to have something like this: blah.o : blah.xyz > some command | sed 'some

Re: [bug #55243] Request for a way to indicate that the same recipe execution produces several targets

> > > blah.h : blah.cc > >> no real recipe was provided, just adding this note for emphasis; this > > last part is how I suggest you solve it > > Perfect but this does not work in the situations I am interested in, > that is where one single atomic command produces several files. Example: >

Re: GNU Make for Java projects

It's been years, but I'll throw in my 2 cents in case it helps. I attempted to make some java stuff build using a makefile and ran into circular dependency issues: foo.java depended on bar.java & vice-versa. When I attempted to compile foo.java by itself it complained about unsatisfied