Ten days have passed since the release of grig 0.7 and I have not received any bug reports until today. Berndt, one of the BSD guys, has discovered that grig is not installable because $(DESTDIR)/share/grig is not created prior to attemting to copy files into the directory. Fortunately, this stuff is done as one of the last things during install, so the installation will work and only the README, ChangeLog and similar files will be missing. I fired up my laptop and could confirm the same behaviour on Suse Linux.
I guess I don’t have to tell you how much this pisses me off! Not because it’s a bug in grig but because it is not due to a coding error, rather due to the blody autoconf/automake – again X-(
I tried to scan through the automake manual to see if I can identify any obvious and correct solution, but no luck. Of course no luck. How can I be such an idiot to expect or to hope that I would be able to find any useful info in the automake manual…
I then tried to compare the auto-thingy infrastructure with the one in gpredict, since that one seems to work without any quirks. I found out the the reason for gpredict install working is that gpredict has a subdirectory beneath the top level pkgdatadir, and this will appearantly cause the installation to create all the directories. That coul be one beautiful solution: Create a subdirectory for data containing nothing but a dummy data file.
I decided that the solution with the dummy data file would be way too crazy and I came up with an alternative solution: explicitly create the datadir before attempting to install. now, how can this be done in a sensible way? Well, I have the mkinstalldirs shell script in the tarball anyway and this script is supposed to be able to create a whole path recursively, so I added the line:
$(top_srcdir)/mkinstalldirs $(DESTDIR)$(pkgdatadir)
This worked fine on my laptop and Berndt confirmed it on his BSD machine. So, this will be the fix and I’ll do that as soon as I’m back within range of CVS.