[Bashdb-remake] How remake just helped me track down a bashdb Makefile problem

[R. B. <ro...@pa...>]

I just came across this situation and the I found the GNU Make
debugger helpful in fathoming what was going on.

Recently there was the infamous palindromic-version number a release
of bashdb. (Well, okay it's close enough: 3.00-0.03). Manfred Tremmel
had some problems in packaging it and noticed the documentation
hard-coded locations of where bash is.

What he did to make this location customized for the particular
installation was to have configure replace these strings in
bashdb.texi.  So he created bashdb.texi.in. It struck me as odd but he
also created bashdb.info.in since bashdb.info is derived from
bashdb.texi.  However I learned later that this was added to get "make
distcheck" to work for him.

Although I don't doubt that Manfred managed to get this to work, no
matter how I tried to merge the patch I was getting an error one way
or another. After spending too much time trying to try just another
test, I took this as an opportunity to use the GNU Make debugger to
help me figure out what's going on.

Of course, I have and advantage that when the GNU Make debugger wasn't
all as helpful as I would like, I can just add another feature to
it. The two things I've just changed in GNU Make are giving a target
trace by default and also listing the command arguments passed when
there is an error. This is helpful in a "make distcheck" because it
was dying in some weird directory several shell levels deep invoked
with target names that are not all that obvious. For example, here
were the arguments neeeded to debug the target where GNU Make was
dying:

   top_distdir=/home/rocky/src/external-cvs/bashdb-3.00/bashdb-3.00-0.04cvs/_build/bashdb-3.00-0.04cvs distdir=/home/rocky/src/external-cvs/bashdb-3.00/bashdb-3.00-0.04cvs/_build/bashdb-3.00-0.04cvs/doc distdir

Right! Like someone in their right mind would be able to figure this
out without some help?

Okay now going *into* the debug session. Well I learned that one
problem could be fixed by setting INFO_DEPS no to refer to $(srcdir)
but to the current build directory. There is no such variable for the
current build directory, but there is a $(top_builddir), which one can
slap a "/doc" to the end of. That got me farther, but then there seems
to be the problem that to build bashdb.info, GNU Make wanted to build
stamp-vti -- the month and edition number -- in $(srcdir) which of
course is not writable.

All of this INFO_DEPS and stamp-vti stuff is put in by automake. And
it seems to hard-code $(srcdir). Looks like a bug to me in automake,
but the whole thing is just so screwy that I wouldn't have a clue if
it is or just another case were the user should have known better the
quirks of automake. I then realized that is better not to have copies
of bashdb.texi and bashdb.info but just write some texinfo variables
in a file external to bashdb.texi (same as version.texi does) and have
bashdb.texi use them. And that seemed to work.