From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Engster Newsgroups: gmane.emacs.devel Subject: Re: Noisy byte compilation on master Date: Mon, 16 Feb 2015 22:11:19 +0100 Message-ID: <87bnktpnns.fsf@engster.org> References: <83egq9ipkn.fsf@gnu.org> <858uggchvx.fsf@stephe-leake.org> <87twz379z2.fsf@engster.org> <87twyndv53.fsf@engster.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1424121109 29885 80.91.229.3 (16 Feb 2015 21:11:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Feb 2015 21:11:49 +0000 (UTC) Cc: "Eric M. Ludlam" , Stephen Leake , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 16 22:11:41 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 1YNSx9-0006cd-Rq for ged-emacs-devel@m.gmane.org; Mon, 16 Feb 2015 22:11:39 +0100 Original-Received: from localhost ([::1]:42466 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNSx9-000364-6E for ged-emacs-devel@m.gmane.org; Mon, 16 Feb 2015 16:11:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44726) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNSx5-00035m-OM for emacs-devel@gnu.org; Mon, 16 Feb 2015 16:11:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YNSx4-0003yi-Ly for emacs-devel@gnu.org; Mon, 16 Feb 2015 16:11:35 -0500 Original-Received: from randomsample.de ([5.45.97.173]:49706) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNSx0-0003wR-UL; Mon, 16 Feb 2015 16:11:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=tk01ists2mBu5taHtU/l/Kqnz3xZ6iLLdL2mCertr50=; b=SJvDj4oG6WSq3EOVOD2EEYIT4kbfnDNpBGf4L/vmVVI0u1ZGq1yFeXERR26YET/uRiyeNucKmGmthbaiKCrOMlXEvNv3uJ8NZcyeOBSexbLQOwNUMK1aSC/Z2Jq1sJks; Original-Received: from ip4d149227.dynamic.kabel-deutschland.de ([77.20.146.39] helo=spaten) by randomsample.de with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YNSws-0004MK-MA; Mon, 16 Feb 2015 22:11:22 +0100 In-Reply-To: (Stefan Monnier's message of "Sun, 15 Feb 2015 21:56:29 -0500") User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.4 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 5.45.97.173 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:183179 Archived-At: Stefan Monnier writes: >> The bigger problem is that now I get a ton of warnings during CEDET >> compilation because you use 'labels' instead of 'cl-labels', but with >> good reason, as the commentary says. Not sure what to do about that... > > Try the 100% untested patch below, which should silence those warnings. Thanks, it works. 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. I'm also trying to get the CEDET tests to work with latest Emacs. One reason they break is that `child-of-class-p' does not accept symbols anymore. This here (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? >> The alternative would be that built-in ELPA thingy, but that's not >> available yet. > > I really hope we can get this "bundle some ELPA packages in the tarball" > working for 25.1. > >> 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. CEDET is more like a framework than an application. It'd be a shame if no core package could depend on anything from it. >> However, the advantage would be that I could ditch a beloved pet-peeve >> of mine, namely editing that file that shall not be named (hint: it >> logs changes). > > The ChangeLog should disappear from master "any time now", so this > should be resolved in any case soonish. That's not what I mean. CEDET has generated its Changelog from the commit logs for years. The problem is that this generated Changelog has to be *heavily* edited to confirm to the strict standards that are required. For instance, there's the requirement that changes have to appear under the date they entered Emacs trunk, and that you should not have several entries from the same author for the same day. So you have to look over all the changes from your merge and combine those that affect the same files/functions/variables. Then there's the problem that the Changelog will also contain changes from files that are only upstream, which you'll have to delete. 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'! So I have to make sure to sort the entries into the correct Changelogs. All of this is a *huge* pain, and - I'm sorry, but I have to repeat myself here - for something I find to be not only useless, but even hurtful to the quality of the commit messages of the project. If moving to ELPA gets rid of Changelogs *completely* (meaning, also in the commit logs), that would be big incentive for me to consider leaving Emacs trunk, although I'd consider that a loss for Emacs core. -David