From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Noisy byte compilation on master Date: Mon, 16 Feb 2015 18:14:47 -0500 Message-ID: References: <83egq9ipkn.fsf@gnu.org> <858uggchvx.fsf@stephe-leake.org> <87twz379z2.fsf@engster.org> <87twyndv53.fsf@engster.org> <87bnktpnns.fsf@engster.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1424128531 17968 80.91.229.3 (16 Feb 2015 23:15:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Feb 2015 23:15:31 +0000 (UTC) Cc: "Eric M. Ludlam" , Stephen Leake , emacs-devel@gnu.org To: David Engster Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 17 00:15:14 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YNUsk-0006If-FE for ged-emacs-devel@m.gmane.org; Tue, 17 Feb 2015 00:15:14 +0100 Original-Received: from localhost ([::1]:43039 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNUsj-0000Av-Mz for ged-emacs-devel@m.gmane.org; Mon, 16 Feb 2015 18:15:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40836) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNUsf-00008W-Rw for emacs-devel@gnu.org; Mon, 16 Feb 2015 18:15:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YNUse-0007W8-Sp for emacs-devel@gnu.org; Mon, 16 Feb 2015 18:15:09 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:36945) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNUsZ-0007HP-75; Mon, 16 Feb 2015 18:15:03 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t1GNExgG010275; Mon, 16 Feb 2015 18:15:00 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 6A19FF86; Mon, 16 Feb 2015 18:14:47 -0500 (EST) In-Reply-To: <87bnktpnns.fsf@engster.org> (David Engster's message of "Mon, 16 Feb 2015 22:11:19 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5219=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5219> : inlines <2192> : streams <1391432> : uri <1856968> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:183182 Archived-At: > The next problem are those "Obsolete name arg 'foo' to constructor" > messages. I cannot simply omit the names as this won't work with older > EIEIO. Indeed, you'd have to use `make-instance'. Or you could use a macro which either drops the name argument or passes it depending on the version of EIEIO with which it's compiled. > (require 'ede/proj-elisp) > (child-of-class-p 'ede-proj-target-elisp 'ede-target) > used to work fine, but now `child-of-class-p' has those cl-check-types > in it. Is that on purpose? Looks like a bug. It's been changed to accept class arguments (rather than class names), but it should also accept class names, as before. >>> Also, if I understand you correctly, this would mean that >>> core packages cannot depend on CEDET. >> Indeed, that'd be the downside. > A pretty major one, I would say. Agreed. > That's not what I mean. I don't understand, then. > For instance, there's the requirement that changes have to > appear under the date they entered Emacs trunk, Obviously, you won't be affected by this requirement any more once Emacs starts generating the ChangeLogs mechanically. > and that you should not have several entries from the same author for > the same day. Not sure where you ot that idea, but we don't have such a requirement. I even often setup such multiple-entries-from-the-guy-same-day *by hand*, when I feel like it helps structure the ChangeLog. > Then there's the problem that the Changelog will also contain changes > from files that are only upstream, which you'll have to delete. How would that affect you, since "we" (i.e. Paul) write the scripts that (will) generate the ChangeLogs (IIUC we'll generate a single ChangeLog for the whole Emacs tree)? > And on top of that, CEDET's files are scattered across the Emacs > codebase, affecting many different Changelogs: not only that for > 'lisp/cedet', but also 'lisp/emacs-lisp', 'admin', 'etc', 'doc', and > there's even one for 'test'! But once we start generating the ChangeLogs mechanically you won't need to care any more (maybe we'll need to care if we want to generate equivalent ChangeLogs, but so far the intention has been to do something simpler). > All of this is a *huge* pain, I understand it's annoying, but I don't understand why you think that us moving to auto-generated ChangeLogs won't solve those problems for you. Stefan