[bug #44742] Double-dep with double-colon rule not built

URL: Summary: Double-dep with double-colon rule not built Project: make Submitted by: mohawk Submitted on: Mon 06 Apr 2015 00:08:02 GMT Severity: 3 - Normal Item Group: B

[bug #44742] Double-dep with double-colon rule not built

Follow-up Comment #2, bug #44742 (project make): Thanks for taking a look! I tried patching my local GNU make 4.1 per your suggestion, and it hasn't helped. Here is a fuller set of steps to repro: # initial setup cpanm --dev --look PDL cpanm ExtUtils::MakeMaker@7.05_19 # 7.05* has double-level p

[bug #44742] Double-dep with double-colon rule not built

Follow-up Comment #3, bug #44742 (project make): Thanks for taking a look! I tried patching my local GNU make 4.1 per your suggestion, and it hasn't helped. Here is a fuller set of steps to repro: # initial setup cpanm --dev --look PDL cpanm ExtUtils::MakeMaker@7.05_19 # 7.05* has double-level p

[bug #44742] Double-dep with double-colon rule not built

Follow-up Comment #5, bug #44742 (project make): It definitely *does* ruin the build. My question is, is this by design or simply a long-standing bug in GNU make? It doesn't happen on BSD make, for instance. ___ Reply to this item at:

[bug #30914] Standard library search path not configurable

URL: Summary: Standard library search path not configurable Project: make Submitted by: edman007 Submitted on: Tue 31 Aug 2010 03:36:36 AM GMT Severity: 3 - Normal Item

include should be relative to current Makefile

ld break for recursive builds. Non-recursive builds would probably welcome the chance to make things simpler (and they seem to be rarer than recursive builds still). A possible solution might be to do the expected thing by default and fall back to CWD-relative includes if the Makefile-relative tar

Re: include should be relative to current Makefile

> >By the same logic, one can use a (module-specific) variable meaning >"here" in each sub-directory's make-file fragments; so foo/config.mk >refers to its source files as $(FOOSRC)/bar.c and so on, rather than >assuming FOOSRC=. (although that likely remains th

Re: include should be relative to current Makefile

> > From: Edward Welbourne >To: Ed H >Cc: bug-make@gnu.org >Sent: Wednesday, May 16, 2012 1:21 AM >Subject: Re: include should be relative to current Makefile > >> ifndef TOP >> >> include ../Makefile >> &

Condtional target-specific variable assignment does not work as expected

The following Makefile: condset: COND ?= one condset: condset2 @echo $@ COND [$(COND)] condset2: COND ?= two condset2: condset3 @echo $@ COND [$(COND)] condset3: COND ?= three condset3: @echo $@ COND [$(COND)] outputs: condset3 COND [three] condset2 COND [two] condset COND [one] I would have

Re: Condtional target-specific variable assignment does not work as expected

rs to manage (imagine a big team where different people are responsible for different phases of some complex process). On Fri, Aug 9, 2013 at 1:53 PM, Philip Guenther wrote: > On Fri, Aug 9, 2013 at 12:59 PM, Ed Hutchins wrote: > ... > > In my case I'd like to have "init"

feature request: $(wildcard) file type filter

whole directory trees automatically, for example. It would be a lot simpler to support posix find -type style qualifiers on on $(wildcard): $(wildcard [,]) where filter is 'f' for plain files, 'd' for directories, 'l' for links, etc. - Ed _

feature request: $(wildcard) file type filter

whole directory trees automatically, for example. It would be a lot simpler to support posix find -type style qualifiers on on $(wildcard): $(wildcard [,]) where filter is 'f' for plain files, 'd' for directories, 'l' for links, etc. - Ed _

.NOTPARALLEL as a dependency

or -j8, for example). As an aside is there any way to determine the original -jN argument? - Ed ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make

error with gmake: overriding macros

the attached makefile works with basic make routine on my unix box and gmake. make-f makefile.simdif mul0 ; # works gmake -f makefile.simdif mul0 ; # works however, when I try to override the textmacro TIMING (defined in the makefile) make TIMING=min -f makefile.simdif mul0; # make comm

Problem setting a variable inside a target

cData-copyright-can.a2l $(DIR_A2LGEN_SETUP)/McData-setup.a2l @echo "A2LSupplier folder not available" endif Ed L Wolf Technical Advisor - Embedded Software e.l.w...@cummins.com Cummins Inc. Mail Code: C7004 1460 National Road Columbus, Indiana 47201 United States

RE: Problem setting a variable inside a target

DIR_A2LGEN_SUPPLIER did have a file called Rte.a2l Ed L Wolf Technical Advisor - Embedded Software e.l.w...@cummins.com Cummins Inc. Mail Code: C7004 1460 National Road Columbus, Indiana 47201 United States From: Martin Dorey Sent: Sunday, September 24, 2023 6:02 PM To: Ed L Wolf ; bug-make

RE: Problem setting a variable inside a target

One more comment. For some reason SUPLLIER_A2l is blank Ed L Wolf Technical Advisor - Embedded Software e.l.w...@cummins.com Cummins Inc. Mail Code: C7004 1460 National Road Columbus, Indiana 47201 United States From: Ed L Wolf Sent: Monday, September 25, 2023 6:10 AM To: Martin Dorey ; bug-make

RE: Problem setting a variable inside a target

DIR_A2LGEN_SETUP)/McData-copyright-can.a2l $(DIR_A2LGEN_SETUP)/McData-setup.a2l @echo "A2LSupplier folder detected but no a2l files present" endif else @cp $(DIR_A2LGEN_SETUP)/McData-copyright-can.a2l $(DIR_A2LGEN_SETUP)/McData-setup.a2l @ech

RE: Problem setting a variable inside a target

is always null. IS there anyway to force this statement to be ran in the exact sequence its listed? Ed L Wolf Technical Advisor - Embedded Software e.l.w...@cummins.com Cummins Inc. Mail Code: C7004 1460 National Road Columbus, Indiana 47201 United States -Original Message- From: Bahm