Re: [non-stop] 01/10 Add "executing" property

[Eli Zaretskii <eliz at gnu dot org>]

> From:  Vladimir Prus <vladimir@codesourcery.com>
> Date:  Tue, 17 Jun 2008 13:50:45 +0400
> 
> Eli Zaretskii wrote:
> 
> >> From:  Vladimir Prus <vladimir@codesourcery.com>
> >> Date:  Mon, 16 Jun 2008 10:42:09 +0400
> >> 
> >> It's actually fairly weird that one has to maintain dependencies by hand,
> > 
> > We are obviously miscommunicating.  What I meant was simple entries
> > like:
> > 
> > * Makefile.in (foo.o): Add bar.c and bar.h to prerequisites.
> > or
> > * Makefile.in (foo.o): Remove foobar.h from prerequisites.
> > 
> > That's a far cry from ``maintaining dependencies by hand''.  
> 
> In fact, it is the same. Why do we, in 2008, need to add 'bar.h' to dependencies of
> foo.o?

I didn't say we needed to, I said that if we do, we should mention it
in the ChangeLog, that's all.  The simple fact is that in this
particular case, the change was to add $(gdbthread_h) to the list of
prerequisites of several targets, like this:

   inf-loop.o: inf-loop.c $(defs_h) $(inferior_h) $(target_h) $(event_loop_h) \
	  $(event_top_h) $(inf_loop_h) $(remote_h) $(exceptions_h) \
  -	$(language_h)
  +	$(language_h) $(gdbthread_h)

If you think this kind of change is ``laughable'' in the year 2008,
please complain to Pedro, who suggested such a change; I didn't.

> That's painful and, honestly, laughable at, thing.

Well, entries such as "Makefile.in (event-top.o): Update." are no less
laughable, because they convey exactly zero useful information beyond
what "cvs log Makefile.in" already tells.  If we want to accept such
entries, why don't we abandon ChangeLog files at all?

By contrast, saying _what_ was changed in the rules of a target gives
me valuable information that is a pain to glean from CVS, unless I'm
interested in the very last change, or know exactly in what version
the change I'm interested in was committed.

That said, I'm no longer young enough to fight Quixotic battles.  If
this is the kind of coding standards the other GDB maintainers want to
adhere to, let's codify them somewhere, and be done with that, so that
I will never again need to start arguments like this one just to be
predictably voted down.