Re: Proposals for new features.

[R. Bernstein]

Paul Smith writes:
...
 > 
 > Note that some of the changes you describe above (such as changing the
 > code to require ISO C89 compilers, adding prototypes, etc.) have already
 > been done in the code base.  I declared a while ago that 3.81 was the
 > last release that would compile with K&R C compilers.  However, I still
 > won't use ISO C99 constructs in GNU make.  Maybe in a release or two.

Here are a couple purely structural things that could be done even in
K&R Compilers:
  * extern declarations for foo.c go in foo.h, not in the global make.h
  * interface documentation such as via Doxygen.

Feel free to cull from remake for this purely mechanical/structural
(and modularity) kind of change.

 > The other question is how much size will this add to the package, etc.
 > I don't want to greatly increase the size of the code, the amount of
 > operating system prerequisites, the size of the documentation, etc.
 > This can easily be solved by making the debugger build something you
 > enable at configure time and keeping the debugger manual in a separate
 > doc (this is probably a good idea anyway).

Sure. remake's autoconf/configure already checks for GNU Readline and
disables the debugger portion if that's not around.

 > Or, a third alternative is to just ensure the right hooks/etc. are added
 > to GNU make and keep the debugger as a separate package.

I've long been a fan of this approach. IBM Mainframe architecture had
what was called a subcommand interface which allowed for external
editors and programming languages. I believe Jeff Korn wrote a Ph.d
thesis on a general debugger interface. What I did was more for
expedience than elegance.