Tue 17 May 2016 10:49:18 AM UTC, comment #5:
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.
|
Mon 16 May 2016 01:51:18 PM UTC, comment #4:
You could get the same behavior as before as long as the dependency list is exactly 1 file:
... though I would probably be more inclined to abandon that approach in favor of something like:
|
Sun 15 May 2016 03:45:30 PM UTC, comment #2:
I'm having a hard time understanding what you're doing, not least because there are apparently arbitrary newlines added to your examples :). Also, I assume the output you expect to get from the operation below would be:
However, that's not what you actually get. What you get (with prior versions of GNU make) is:
If you change the makefile to show the deps in the loop you'll see what's happening:
So you can see why you get the output you do: there are actually only three "words" in the FILEDEPS variable, not four, because the newline is not considered to be a word-separating character in this context. Which is sort of bogus (IMO). Your setup is somewhat rickety anyway: if you have any whitespace at the end of a line, for example, it will break (even in the old version of GNU make).
The change you're running into isn't directly related to bug #46995. As above, previously make had a kind of schizophrenic attitude towards newlines: sometimes they were treated as word-separating and sometimes they were not treated as word-separating. I made a change to sanitize this, so that make treats newlines as word-separating whitespace in virtually all situations, which is why you're seeing this; if you run the above makefile using make 4.1.90 you get:
This is much more clean, and IMO correct, but it does break your usage. To work around it, you can use subst to replace newlines with some other character that you're sure will never appear in your FILEDEPS, then convert it back again, like this:
which should work equivalently in both old and new versions of GNU make. If for some reason this isn't going to work please provide updated details for why.
|
Fri 13 May 2016 02:41:26 PM UTC, original submission:
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?
|