Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 977CD431FBC for ; Sun, 19 May 2013 05:14:53 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBdds7DU2Qge for ; Sun, 19 May 2013 05:14:46 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by olra.theworths.org (Postfix) with ESMTP id A23A5431FB6 for ; Sun, 19 May 2013 05:14:46 -0700 (PDT) X-AuditID: 1209190e-b7f4f6d000005142-b5-5198c2354131 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id E3.D1.20802.532C8915; Sun, 19 May 2013 08:14:45 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r4JCEiV2030529; Sun, 19 May 2013 08:14:45 -0400 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91]) (authenticated bits=0) (User authenticated as amdragon@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r4JCEgr6002584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 19 May 2013 08:14:43 -0400 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.80) (envelope-from ) id 1Ue2Vd-0007hu-NG; Sun, 19 May 2013 08:14:41 -0400 Date: Sun, 19 May 2013 08:14:40 -0400 From: Austin Clements To: David Bremner Subject: Re: [PATCH] emacs: Compute build dependencies to fix byte compile issues Message-ID: <20130519121440.GE5999@mit.edu> References: <1368821611-24110-1-git-send-email-amdragon@mit.edu> <87y5bbjk4q.fsf@zancas.localnet> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87y5bbjk4q.fsf@zancas.localnet> User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRmVeSWpSXmKPExsUixG6nrmt6aEagwaQ31hY3WrsZLa7fnMns wOTxbNUtZo8th94zBzBFcdmkpOZklqUW6dslcGV8e7GaseA8Z8X3/xMYGxgXsHcxcnJICJhI tPa+Z4OwxSQu3FsPZHNxCAnsY5SY0HCcEcLZyCgxpecOC4Rzmkli95PPzBDOEkaJl03bmEH6 WQRUJU53HmIBsdkENCS27V/OCGKLAMWvbpsMtoNZQFri2+9mJhBbWCBY4mbbCbB6XgFtiZPX VoPZQgLJEot/rGCDiAtKnJz5hAWiV0di59Y7QHEOsDnL/3FAhOUlmrfOBjuBU0BX4uSJx2Dl ogIqElNObmObwCg8C8mkWUgmzUKYNAvJpAWMLKsYZVNyq3RzEzNzilOTdYuTE/PyUot0jfVy M0v0UlNKNzGCIoFTkm8H49eDSocYBTgYlXh4Nd5NDxRiTSwrrsw9xCjJwaQkyrty34xAIb6k /JTKjMTijPii0pzU4kOMEhzMSiK8aROBcrwpiZVVqUX5MClpDhYlcd4rKTf9hQTSE0tSs1NT C1KLYLIyHBxKEry8B4EaBYtS01Mr0jJzShDSTBycIMN5gIZfPwAyvLggMbc4Mx0if4pRUUqc lwOkWQAkkVGaB9cLS1SvGMWBXhHmfQnSzgNMcnDdr4AGMwENZr02FWRwSSJCSqqBkXnC4S1v Guq5b2x9qG986btDl/JV9q6HV5/u4u6ULXN/LerftDPwwNqwur2c05YxrVb7NEt+1iJRrq6v qfY/3Rb7HeH4f8jg2U6PzTtSu85/aNl7eWLBYp7MKgGug/VTdGPbM4WNDQ1bWvh2i6kK/0jU ur9ltlv6tMW7/8ftO3Mj5PtM+5Vn1JVYijMSDbWYi4oTAZW2MJ8vAwAA Cc: notmuch@notmuchmail.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 12:14:53 -0000 Quoth David Bremner on May 19 at 8:15 am: > Austin Clements writes: > > > > This patch addresses these problems by computing make dependency rules > > from the (require 'x) forms in the Elisp source files, which we inject > > into make's dependency database. > > this seems to work as advertised. > > > +;; > > +;; Copyright © Austin Clements > > I guess you need a copyright year? Strangely, none of the Elisp files have copyright years. But maybe they should? > > + ;; Is it a (require 'x) form? > > + (when (and (listp form) (= (length form) 2) > > + (eq (car form) 'require) > > + (listp (cadr form)) (= (length (cadr form)) 2) > > + (eq (car (cadr form)) 'quote) > > + (symbolp (cadr (cadr form)))) > > This might be a corner case, but formally can't the argument to require > be a variable or even a function call? Maybe this never happens in > practice. That is technically true (really, it can be an arbitrary expression), but I don't have an environment in which to evaluate that expression, so I opted for only supporting the obvious static case, which also happens to be the only case that matters for the notmuch code.