[bug #48274] adding -j option to MAKEFLAGS no longer works

[Oliver Kiddle]

URL:
  

 Summary: adding -j option to MAKEFLAGS no longer works
 Project: make
Submitted by: opk
Submitted on: Mon 20 Jun 2016 12:16:17 PM CEST
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.2
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None

___

Details:

As of version 4.2, it no longer works to add a -j option to MAKEFLAGS from
within the Makefile. This was used in our common include files so that
parallel builds would be enabled by default and so that we could automate
selecting an appropriate default number of jobs on different systems.


JOBS ?= $(shell /usr/sbin/psrinfo | head -8 | wc -l)

MAKEFLAGS += -rRL -j $(JOBS) $(if $(filter output-sync,$(.FEATURES)),-O )$(if
$(findstring test,$(MAKECMDGOALS)),-k)

all: three two

three:
sleep 3

two:
sleep 2


Ideally it would be easy to both force a default number of jobs and honour and
explicit -j option passed on the command-line to gmake.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Oliver Kiddle]

Follow-up Comment #5, bug #47913 (project make):

Using subst to replace newlines with some other character works fine and I'm
happy with that as a solution. Thanks. I prefer that to the MAKE_DEPS macro
because it is backwards compatible with the individual Makefiles (they span a
large number of projects and directories).

By the way, my original Makefile had the lines inside the FILEDEPS macro
indented with a couple of spaces. Sorry but I couldn't (and still can't) find
how to do the required markup for the Savannah tracker in the Savannah help.
Thanks again.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[Oliver Kiddle]

URL:
  

 Summary: newlines lost with $(foreach)
 Project: make
Submitted by: opk
Submitted on: Fri 13 May 2016 04:41:26 PM CEST
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: Any
   Fixed Release: None
   Triage Status: None

___

Details:

I tried the 4.1.90 release candidate with my Makefiles and found a problem due
to it behaving differently to previous releases with regard to newlines being
lost from a variable when using $(foreach).

Simplifying things a lot, what I have is roughly along these lines:

define FILEDEPS
  File.cpp: File.h
  Other.cpp: Other.h
endef

here = here

ifdef FILEDEPS
  $(eval $(foreach dep,$(FILEDEPS),$(or $(filter :,$(dep)),$(abspath
$(here)/$(dep)

endif

To put this into context, I use a non-recursive setup where a small Makefile
in each individual directory contains definitions for that directory's
contents and then includes a complex common makefile which defines all the
rules and includes all the other Makefiles. So this allows certain extra file
depenencies to be defined without specifying the directory. here is actually
set with something like the following so that it points to the directory of
the current directory specific
Makefile:

here := $(dir $(lastword $(filter-out %.d %.D %.mk %/config.inc $(lastword
$(MAKEFI
LE_LIST)), $(MAKEFILE_LIST

With 4.1.90, I get a "multiple target patterns" error. If you change $(eval)
for $(info), current releases of GNU make show the two file dependencies. With
4.1.90, it has wrapped them onto a single line.

Is this an intentional change, a bug or just an implementation quirk that I
shouldn't have relied on?





___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

output from $(error) lost with output sync

[Oliver Kiddle]

Given the following Makefile, the output from the error function is
being lost when the gmake 4 output-sync is enabled:

foo: $(OBJS)
echo $(or $(filter %.o,$^),$(error No input files for library: $@))


% gmake
Makefile:2: *** No input files for library: foo.  Stop.
% gmake -O
%

With $(info ) and $(warning ), there is no problem.

Oliver

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

$(origin GNUMAKEFLAGS)

[Oliver Kiddle]

It seems that $(origin GNUMAKEFLAGS) returns `environment' while
$(origin MAKEFLAGS) returns `file'. Is there a reason for this
discrepancy? Unlike MAKEFLAGS, it doesn't appear to be exported to child
processes.

Even `file' seems a strange value: wouldn't default make more sense
unless it really is assigned from within the file?

Thanks

Oliver

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #18305] target specific variables with conditional assignments

[Oliver Kiddle]

URL:
  http://savannah.gnu.org/bugs/?18305

 Summary: target specific variables with conditional
assignments
 Project: make
Submitted by: opk
Submitted on: Wednesday 11/15/2006 at 13:44
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
   Component Version: 3.81
Operating System: Any
   Fixed Release: None

___

Details:

If a target-specific conditional variable assignment is used, it
unconditionally overrides any inherited target-specific variable. Try the
following Makefile with and without the first line. The command is always run
with the argument 'two'.

all: TARGET = one
all: lib

lib: TARGET ?= two
lib:
make -f second.mk $(TARGET)


The bug might arguably be that the target-specific variable is being
inherited at all though that's actually a useful feature for me. I can get
this Makefile to work as I want by using $(or $(TARGET),two).

Oliver






___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18305

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make