From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: Towards a cleaner build Date: Sun, 09 Jun 2019 15:48:03 +0200 Message-ID: References: <83zhn6zkgf.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="36095"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Eli Zaretskii , Noam Postavsky , Emacs developers To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 09 15:48:39 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hZyBY-0009Ci-Tl for ged-emacs-devel@m.gmane.org; Sun, 09 Jun 2019 15:48:37 +0200 Original-Received: from localhost ([::1]:35938 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hZyBX-0005mf-9X for ged-emacs-devel@m.gmane.org; Sun, 09 Jun 2019 09:48:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51776) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hZyBB-0005mU-K3 for emacs-devel@gnu.org; Sun, 09 Jun 2019 09:48:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hZyBA-0007oH-Ib for emacs-devel@gnu.org; Sun, 09 Jun 2019 09:48:13 -0400 Original-Received: from quimby.gnus.org ([80.91.231.51]:38510) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hZyBA-0007m4-C8; Sun, 09 Jun 2019 09:48:12 -0400 Original-Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=stories) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hZyB2-0003XF-3Y; Sun, 09 Jun 2019 15:48:06 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEUWA0N5R5AqGU8SAUAO ADscCEcPADr330ScAAACJElEQVQ4jV2Tza7aMBCFp6RmTVx1Txwla4tJ7gP0WqzB1KwRcfz+j9Az dgyiRlHCfJk58xdK0S3fzOzcOb0OPwLJHWD6AMtiM3AZuGxz0QmgApyAmOIZgXEQoYC4geSSe4Pn mOL3TYiA6gHx49MYow2HCYHwzjD9ufHsKY0dgBnMdobr4HED8Fd5MH0FRiNED4117NPAngMrlYK9 J7+u6l6yQqnG64/qeQOzCT3/DK7/HzxbYyQJb8YlxfjNNdQcaOe9Og7hbzxLTytAHrYhgmXCxZYA WIA3t6axF6BpYsukAsU5SekmF3MUHwkkYE0PsQVcp0uzAbpQfKRc7965ibnacaIo4yBJV8ySBeXR riEMoQzypRAIzc7i9zJ7nAYAaMJ86JH8fqT12MM+E0AQMEnnrrkl/VacADye01dSezMMc28/gNN4 Oa+TVRey2Q6ALRhQRwEwNJsGPE6d0d3uNfdjBe4kjVK+rsMLIEP8HYsGTJdPIAUupPwAW6iAeVty S8FUIHMBEBm0QAW4VEBe8pF5GJttagOc8/H6BaqG3WmtTfc7q789eNZtl3976dPbQ+ZJmE3bjkwC 1NbE6GZC9K5tf3FTxp39KLkfbTlQv8k8OHcRM39IyCtICGVP4FGWIXZai8uNv2TkXHolrTgZI+DA S9q2BAAfvCxHFilfRklagHhn+Q1wyQpfCRY9gzEDa1UFeM7gALssSRVH30uoQ64h2/0/wFQDrB5H JcEAAAAASUVORK5CYII= In-Reply-To: (Stefan Monnier's message of "Wed, 29 May 2019 11:48:53 -0400") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 80.91.231.51 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.org gmane.emacs.devel:237344 Archived-At: Stefan Monnier writes: >> But as a macro that expands to (basically) `progn', then the byte >> compiler just sees the `progn' and is unable to do anything with the >> form. > > You can use byte-compile-macro-environment to override the default > definition of the macro during compilation. I've been poking at the machinery here, and I'm not quite sure I understand. If I put a different definition of with-suppressed-warnings into byte-compile-initial-macro-environment, then that will indeed override the normal definition. But that variable is consulted before compilation is done, and it can't do any bindings that affect the compilation itself, I think? I mean, it can alter the global state, but not do any let bindings. Or did you mean that that should return an intermediary function and then do the byte-hunk-handler thing as in my code sketch? *implements* Oh, wow, that worked. :-) It always helps to ask, apparently. But if you meant something else, please correct my new misunderstanding. I've created a new branch for this, and I'll push when I've cleaned things up slightly. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no