[Bashdb-devel] just another make debugger?

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

Masatake YAMATO writes:
 > Do you know this article?
 > http://www.cmcrossroads.com/ubbthreads/showflat.php?Number=52560

It seems a tour-de-force effort. Clever for what one can manage to
squeeze out of GNU Make. The debugger builds on that author's other
GNU Make tour-de-force set of macros called GMSL which adds boolean
operations and some simple mathematical functions to GNU Make.

Although from a theoretical standpoint this is interesting and clever
-- implementing integers by representing them in unary as lists --
clearly if this is needed it should be done inside GNU Make. (But
prototyping it as GNU make macros as the author has done is clearly a
great idea!) One consequence of GMSL's unary word-list approach to
representing numbers is that it doesn't scale all that well - at
present only numbers up to something like 256 can be represented. And
as numbers get larger it takes linearly longer (rather than
logarithmically longer) to count/convert them.

Getting back to the GMD (the debugger) rather than GMSL.  I think one
of its strong points is in helping out with the macro expansion phase
of GNU make which occurs before any dependency checking is done.

I tried using it and, alas, I didn't find it very helpful in any of
the problems I've encountered using GNU Make and automake. That said,
if others have tried this and generally found it effective, I'd be
interested learning of those experiences -- what one did to track down
the GNU Make problems using this tool, etc.

The GMD approach does have an advantage of working on top of the
existing GNU Make 3.80. It would have more of an advantage if it
supported make systems other than GNU Make with versions equal or
close to 3.80.  And finally, one needs to
modify your Makefile to add: 
  include gmd
in order to use the debugger.

Hmmm... Perhaps I should add a command-line option allow one to
specify an include command to get run before makefile processing. In
any event, GNU Make currently doesn't have any such thing.

So:
1) the narrow range of "make" systems supported (same as remake)
2) the need to have this extra code around (same as remake) and 
3) the need to modify a makefile to put in the include (*not* 
   required by remake)

narrows the gap between compiling and installing another binary such
as remake versus this approach.

But although *not* having to install a new binary is an advantage, I
think that's also a disadvantage, For me it's deja vu. Recall that
before my patches to bash 2.05b, writing a debugger for Bash was
really not usable in practice. Really the problem lay in Bash, not
someone's ability to write debugger code via "trap DEBUG".

Sadly, I think the same is true for GNU Make.

One last thought. Although I haven't contacted the author of GMSL/GMD
about this, it might be possible to include one this along with remake
or a stripped-down version with the slow parts (like integer
conversion) implemented in GNU Make. In other words get the best of
both worlds. However remake is still too new, still too much out of my
control and perhaps even too fragile to widen its scope larger at this
point. (If others got involved - hint, hint - that might be a
different story ;-)