Opened 11 years ago
Closed 11 years ago
#1558 closed defect (fixed)
make error in gui/images no directory created because of wrong pattern matching
|Reported by:||pertusus||Owned by:|
To reproduce, you need first to remove the images/symbol directory in the dist directory. For example for me it is
$ rm -rf dist.x86_64-unknown-linux-gnu/etc/gui/images/symbols/
then go to gui/images and issue make:
cd gui/images make /usr/bin/install -c -m 644 symbols/basic/arrow1.png /home/dumas/src/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/gui/images/symbols/basic/arrow1.png /usr/bin/install: cannot create regular file `/home/dumas/src/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/gui/images/symbols/basic/arrow1.png': No such file or directory make: *** [/home/dumas/src/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/gui/images/symbols/basic/arrow1.png] Error 1
If I have correctly understood what happened this is quite vicious. The issue is that there are 2 patterns for installation of png files, one for the png files directly in the directory and one for the png files in symbols/*/. The problem is that the pattern for png files directly in the directory also match files in the symbols/*/ directories.
With my make version, indeed the following pattern:
$(ETCDIR)/%.png: %.png | $(ETCDIR) $(INSTALL_DATA) $< $@
for instance and upon expansion becomes
$(ETCDIR)/symbols/arrow1.png: symbols/arrow1.png | $(ETCDIR) $(INSTALL_DATA) $< $@
which is almost right, but not quite as intermediary directories are not created.
This is in fact documented in the GNU make manual: http://www.gnu.org/software/make/manual/make.html#Pattern-Match:
"When the target pattern does not contain a slash (and it usually does not), directory names in the file names are removed from the file name before it is compared with the target prefix and suffix."
And also I believe that the second rule is chosen because all the prerequisites exist:
"Note however, that a rule whose prerequisites actually exist or are mentioned always takes priority over a rule with prerequisites that must be made by chaining other implicit rules."
Otherwise, the right rule would win because it has a shorter stem.
I have no idea what should be done to fix that.
Change History (6)
comment:1 by , 11 years ago
follow-up: 3 comment:2 by , 11 years ago
|Milestone:||6.4.2 → 6.5.0|
Please, backport any bugfixes to 6.5
comment:3 by , 11 years ago
comment:4 by , 11 years ago
|Milestone:||6.5.0 → 6.4.3|
|Priority:||normal → blocker|
comment:5 by , 11 years ago
See also related #1643
comment:6 by , 11 years ago
|Status:||new → closed|
Should be solved in all active branches. Closing for now...
Replying to pertusus:
I don't get this behaviour (with 3.82). I encountered a different bug, namely that it matched the subdirectory rule:
and created directories named .../symbols/base/arrow.png/ etc; fixed in r50581.
This doesn't apply, as all of the pattern rules contain at least one slash.
It isn't clear what "mentioned" means, but r50581 might fix this, as it adds a non-pattern rule for each of the category subdirectories.