From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.help Subject: Re: eval-when-compile and require Date: Tue, 21 Nov 2017 17:55:34 +0100 Message-ID: <86fu97wozd.fsf@zoho.com> References: <86o9nwwa37.fsf@zoho.com> <20171121072913.GA11830@tuxteam.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1511283397 25463 195.159.176.226 (21 Nov 2017 16:56:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 21 Nov 2017 16:56:37 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Nov 21 17:56:29 2017 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eHBqX-00067U-2M for geh-help-gnu-emacs@m.gmane.org; Tue, 21 Nov 2017 17:56:29 +0100 Original-Received: from localhost ([::1]:35439 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eHBqe-0007fh-C9 for geh-help-gnu-emacs@m.gmane.org; Tue, 21 Nov 2017 11:56:36 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44897) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eHBqA-0007e4-Cp for help-gnu-emacs@gnu.org; Tue, 21 Nov 2017 11:56:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eHBq5-0001RK-Jh for help-gnu-emacs@gnu.org; Tue, 21 Nov 2017 11:56:06 -0500 Original-Received: from [195.159.176.226] (port=38908 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eHBq5-0001Qp-C1 for help-gnu-emacs@gnu.org; Tue, 21 Nov 2017 11:56:01 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1eHBpq-0003cn-Mg for help-gnu-emacs@gnu.org; Tue, 21 Nov 2017 17:55:46 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: help-gnu-emacs@gnu.org Original-Lines: 74 Original-X-Complaints-To: usenet@blaine.gmane.org Mail-Copies-To: never Cancel-Lock: sha1:4psMnUGgr7dQbNhhL7KxfZg+PnM= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:115028 Archived-At: t wrote: > You use this when you require foo's services > at compile time. > > The most common case would be that you > require macro definitions from foo: there, > (require 'foo) would arrive too late. > The compiler is the one which has to expand > the macros, so their definitions are needed > during the compile phase. Actually that is quite common with all the CL macros. And I've never had any warnings or problem with those. One example is cl-incf is a Lisp macro in `cl-lib.el'. Here is another situation cl-caddr is a compiled Lisp function in `cl-lib.el'. (cl-caddr X) This function has a compiler macro `cl--compiler-macro-cXXr'. What does it mean the "function has a compiler macro"? > Another example would be to do some > pre-calculation you don't want to repeat at > run time (because it takes too long, or > because you want to make sure that its > results stay stable) OK, not familiar with that situation... > Note that when you need something *both* at > compile and at run time, eval-and-compile is > your friend. Likewise... >> Here I'm not following. Of course the stuff >> should be compiled. And if it isn't, the >> above enclosement with `eval-when-compile' >> helps by... breaking it? > > Hm. What gets broken? With `eval-when-compile', if it does what it says, and without compilation, won't the definitions be void with the `require' never being reached? >> Besides there are no warnings with plain >> `require', so what does it all mean? > > Then you don't seem to need whatever foo > provides at compile time => you only need > a plain "require". Well, sometimes not even that! Possible explanation interference from other files being compiled, or being in a compiled state, that are required from the file... -- underground experts united http://user.it.uu.se/~embe8573