#1558: make error in gui/images no directory created because of wrong pattern
matching
-----------------------+----------------------------------------------------
Reporter: pertusus | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.2
Component: Compiling | Version: svn-trunk
Keywords: | Platform: Linux
Cpu: x86-64 |
-----------------------+----------------------------------------------------
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.
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1558>
GRASS GIS <http://grass.osgeo.org>