From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6859 invoked by alias); 17 Jun 2008 18:32:06 -0000 Received: (qmail 6742 invoked by uid 22791); 17 Jun 2008 18:32:05 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout7.012.net.il (HELO mtaout7.012.net.il) (84.95.2.19) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 17 Jun 2008 18:31:35 +0000 Received: from conversion-daemon.i-mtaout7.012.net.il by i-mtaout7.012.net.il (HyperSendmail v2007.08) id <0K2M00J00DA8C200@i-mtaout7.012.net.il> for gdb-patches@sources.redhat.com; Tue, 17 Jun 2008 21:14:50 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.229.217.57]) by i-mtaout7.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0K2M00JY3DCP8A60@i-mtaout7.012.net.il>; Tue, 17 Jun 2008 21:14:50 +0300 (IDT) Date: Tue, 17 Jun 2008 20:38:00 -0000 From: Eli Zaretskii Subject: Re: [non-stop] 01/10 Add "executing" property In-reply-to: X-012-Sender: halo1@inter.net.il To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Reply-to: Eli Zaretskii Message-id: References: <200806152203.14626.pedro@codesourcery.com> <20080616012617.GA8944@caradoc.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-06/txt/msg00323.txt.bz2 > From: Vladimir Prus > Date: Tue, 17 Jun 2008 13:50:45 +0400 > > Eli Zaretskii wrote: > > >> From: Vladimir Prus > >> 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.