make debugger thoughts

[R. Bernstein]

With steady progress, my debugger for make has gotten good enough to
be called "alpha" and good enough to make available in public under
version control.  (See below for thoughts on the public version
control).

Although there are a number of gaps listed in TODO, (like the ability
to keep global state global across subshell returns), the debugger is
very usable -- at least for me. It passes all the regression tests
with the exception of one where some commands are getting echoed that
shouldn't; right now I don't know why that's so.

Using the debugger I've learned something about Makefiles, those
produced by automake, and have been able to pinpoint some problems --
even if in some cases I'm still clueless as to how to get "make" or
"automake" fix them.

For example, one thing I learned is that in automake-produced
Makefiles, even though "all" is listed as the first target, it often
isn't the first target to trigger! It appears that
$(srcdir)/Makefile.in is -- and I don't ask me why. I imagine that as
folks start using this, the may be able to *understand* "make" better
and perhaps even write better or more efficient Makefiles.

In the process of the small changes to add better support for error
reporting and debugging, I've been also making changes to the code to
make more modern conventions. For example:

 - the source code now lives in a src directory,
 - configure.ac rather than configure.in is used, 
 - the prototypes for xxx.c are in xxx.h 
 - documentary comments at are found beginning of a function 
   are in the headers in doxygen format.
 - headers can be included in any order since they include what they need
 - headers have tests to make sure they are included only once. 
 - gcc -Wall warnings have been removed

Although none of this is strictly needed for better error reporting
and debugging, any code I may have to deal with, I may as well make as
palatable as possible. 

On the other hand, what has *not* been all that important to me has
been ensuring this builds and runs on a C compiler that isn't
C99-compliant.  Also right now I may have broken the ability to run on
OS's where there was a bit of specialized conditional compilation
(e.g. AMIGA or VMS), custom Makefiles, or build systems and OS's that
don't support automake and autoconf.  For that, there's always good
old GNU make version 3.80.

Given this split in goals, I think it best to maintain this initially
as a seperate track. Although this track is alpha, I think it has some
important and useful changes and needs early exposure to best grow
this the right way. I don't think it should be tied down to the GNU
make 3.81 release schedule and similarly I don't think the 3.81
release schedule should be tied down to having this be flawless.

Two possibilities I see for this then are in GNU make's CVS as a
separate branch, or completely outside such as for example bashdb's
CVS (in sourceforge.net). The latter is the most convenient for me
since that's an area I already have write access to and can easily
make releases from. I've used that in the past for example to extend
ddd to support the new bash debugging I wrote. 

As Masatake YAMATO has pointed out, down the line I'll need to set up
GNU arch (http://www.gnuarch.org/) or something like that in order to
track changes across the two branches.

Thoughts, comments? 

Oh yeah, a tarball snapshot of the latest version of the debuggers is 
http://bashdb.sourceforge.net/libcdio-0.69cvs.tar.gz