make error in gui/images no directory created because of wrong pattern matching

[pertusus]

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) $< $@

also matches

$(ETCDIR)/symbols/arrow1.png

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.

[glynn]

Replying to pertusus:

I don't get this behaviour (with 3.82). I encountered a different bug, namely that it matched the subdirectory rule:

$(ETCDIR)/symbols/%: | $(ETCDIR)/symbols

and created directories named .../symbols/base/arrow.png/ etc; fixed in r50581.

"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."

This doesn't apply, as all of the pattern rules contain at least one slash.

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."

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.

[annakrat]

Please, backport any bugfixes to 6.5

Thanks

[martinl]

Replying to annakrat:

Please, backport any bugfixes to 6.5

Already fixed in 6.5, now also backported to 6.4 (r51478).

[martinl]

See also related #1643

[martinl]

Should be solved in all active branches. Closing for now...