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: Sun, 15 Feb 2015 16:58:16 +0100 Message-ID: <87twyndv53.fsf@engster.org> References: <83egq9ipkn.fsf@gnu.org> <858uggchvx.fsf@stephe-leake.org> <87twz379z2.fsf@engster.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1424015948 21337 80.91.229.3 (15 Feb 2015 15:59:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 15 Feb 2015 15:59:08 +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 Sun Feb 15 16:58:59 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 1YN1b1-0005Or-7J for ged-emacs-devel@m.gmane.org; Sun, 15 Feb 2015 16:58:59 +0100 Original-Received: from localhost ([::1]:35751 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YN1b0-00011N-Ha for ged-emacs-devel@m.gmane.org; Sun, 15 Feb 2015 10:58:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45223) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YN1aj-00011I-Ki for emacs-devel@gnu.org; Sun, 15 Feb 2015 10:58:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YN1ae-0003k4-HQ for emacs-devel@gnu.org; Sun, 15 Feb 2015 10:58:41 -0500 Original-Received: from randomsample.de ([5.45.97.173]:47490) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YN1aY-0003jA-OW; Sun, 15 Feb 2015 10:58:30 -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=OYB2tVhq58lAj3gjhT5Erp+DOgfi62KJaQ+UdFU/3LQ=; b=I3LoyA8EFJQcZTj7KFcqKmgMBJngkSOScIF+pufo4mH7WAjnlj3LF6TRWNmS9HJg3p6031UwIEPd4NJUf+Pyjgy4rmN/xrRCM68l5ca4491dWhmJj8gFL6+MGxytWWJj; 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 1YN1aQ-0005oI-4L; Sun, 15 Feb 2015 16:58:22 +0100 In-Reply-To: (Stefan Monnier's message of "Wed, 04 Feb 2015 10:45:27 -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:183090 Archived-At: Stefan Monnier writes: >>>> Alternately, non-core CEDET can provide a compatibility file that >>>> defines cl-defmethod etc in terms of defmethod for older emacsen. >>> Hmm... that's an idea. >>> I could provide a cl-generic.el on GNU ELPA to provide cl-defmethod via >>> EIEIO, and then CEDET could make use of the new macros. >>> WDYT? >> Fine with me. We could also put it in CEDET upstream so people don't >> have to install it. > > I have now added a cl-generic forward compatibility package to GNU ELPA. > It should hopefully work for any Emacs with EIEIO. Well, it just occured to me that it's not that terribly useful to have it in ELPA, as you need that macro during byte-compilation, and ELPA packages are not available from 'emacs -Q'. So I guess I'll have to install in CEDET upstream. 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... >> Note that I currently have no way of syncing CEDET with Emacs. > > Is there something we can do about that? We need a plan how to integrate CEDET easier now that both projects moved to Git. I'm leaning towards importing lisp/cedet from a stable upstream branch as a subtree. This would at least take care of merging from CEDET to Emacs. The other way round is not as easy, but not terribly difficult either. The alternative would be that built-in ELPA thingy, but that's not available yet. Also, if I understand you correctly, this would mean that core packages cannot depend on CEDET. 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). >> So if you have a script or similar to change the calling convention, >> please tell me and I run it over the upstream code. > > I used the sed script below along with: > > for f in $(grep -l '(defmethod' lisp/cedet/**/*.el); do > echo $f > (rm $f; ./_cl-generic-rewrite.sed >$f) <$f > done Thanks, that's very useful. I've now pretty much removed EIEIO from CEDET upstream, so its development is now solely in Emacs. On thing less to merge. Juhu! -David