Received: (at 77745) by debbugs.gnu.org; 21 Apr 2025 23:57:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 21 19:57:14 2025
Received: from localhost ([127.0.0.1]:41076 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u710k-0001r4-4r
for submit <at> debbugs.gnu.org; Mon, 21 Apr 2025 19:57:14 -0400
Received: from mail-ua1-x932.google.com ([2607:f8b0:4864:20::932]:42415)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <bjourne@HIDDEN>) id 1u710h-0001qn-4D
for 77745 <at> debbugs.gnu.org; Mon, 21 Apr 2025 19:57:11 -0400
Received: by mail-ua1-x932.google.com with SMTP id
a1e0cc1a2514c-86d587dbc15so4158724241.1
for <77745 <at> debbugs.gnu.org>; Mon, 21 Apr 2025 16:57:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1745279825; x=1745884625; darn=debbugs.gnu.org;
h=content-transfer-encoding:cc:to:subject:message-id:date:from
:in-reply-to:references:mime-version:from:to:cc:subject:date
:message-id:reply-to;
bh=7anPnOob4a7KX+cH+Ohwf7W+TFVqjsVIbB55/mrTo1A=;
b=KsD33ffFD971tsStD4Q4uDAf3W+zdYvFzd+Wj1Sfv8tnaLsLOF7smfrLkQegGPDRAi
B8khpdobwbvYPTEkyYfLt9IvflEQPpU8j4WwJm3ACSVJ0Eu6e6ACRek6zjvudvzZpWyg
PavFiUhv3dvJwWx/3X0sGUUkADmCG1AP6R0RtdpRgPxgivNXVSugWHcQwLGFe34vM2bT
Fy+5BU9x3VGC4ReTfe5oo52DzQrQPGFvYGu6wi9IXijcYnOuhfVyJ8yQVnkS4xknxuSc
gGmRZFRMgzuIjkYSJb9icLT0JyiHScBjx+ZTScQSckynsNbTdEPSacL/ZmxewMbTZkl5
lXRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1745279825; x=1745884625;
h=content-transfer-encoding:cc:to:subject:message-id:date:from
:in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=7anPnOob4a7KX+cH+Ohwf7W+TFVqjsVIbB55/mrTo1A=;
b=EVKFNR73cTT9L9xP/frEusz7Chyupr4Tn9mc5DABIvf9Bi3Qdw9YcqVehWPJRW8G/O
KdRXMhr4RR9hOGwo9P9Jhs55y/amsTDyZXnWIIlG2BBXJFenV4NbZ/FpXxBueHH+YKDd
mW68wr0Gp66UgAVdlq0mcvr2VAQKRjlspipJh5DXevQAxgJro6kUk1sBSXweC6dh7XAx
0wazy5hxq86IP0HbcLX4Cz4BaOGBBryg/xN0qL8l4uDw3nEeImPaF8FkYd7jK53yewOc
jmuHO/TSCj0h/ihG8WjUqQhzQFB+GT0oyV21+J+1qHGQDbB562GkzBtVGvRr4TEZkiff
My/Q==
X-Gm-Message-State: AOJu0YwQXijeDj9K47ilDzjwvu28Offo03OwwkS0vSn5NKunboQsGCh1
gPc2s1qG8lN0ajBbbxwIyVTDtRXVsR7kp89GhdY+zJ3VOv9iCbetlXHQXNgl5LfyNw1HBpq7klx
LNT8obCPdT8gIaK4sBsbm+k3uN1yOkg1FJDk=
X-Gm-Gg: ASbGncuc5Vd/3/aSWw02xYEYLcAHZYrpuwSPN7G0mNhb/gJPSxmEoQdukhvB6Z7o23S
0uX7s6PT1/xEhOsWYZc8F2O+CBV/CoFaYV0S8YCLsSt293DOoH/0Pms5pgxy60xL7loeZp4o0yw
kNUz9s/GHb702ZItkHfmyn3u4=
X-Google-Smtp-Source: AGHT+IHpeT814+wDkq31mrYZ4Vqq8Snz0j1ikL/Kxw4C5k+Sk/ZVQGmIGmdVg0LVd/jT4kKOWwrDpyvuvn90hue+nbw=
X-Received: by 2002:a05:6102:8087:b0:4c2:fccb:a647 with SMTP id
ada2fe7eead31-4cb7dd642b7mr14248499137.5.1745279825257; Mon, 21 Apr 2025
16:57:05 -0700 (PDT)
MIME-Version: 1.0
References: <CALG+76edL6PRmODyibLDtAk6_cAy2a4JZ6dV4mRGhRO1h-WwNA@HIDDEN>
<86r01yoe8y.fsf@HIDDEN>
<CALG+76fvOrn_7cRnj4PJ09-1Jsowq9iS59xeEPS0Yi2BK=ac8A@HIDDEN>
<86jz7qo6pk.fsf@HIDDEN>
<CALG+76d+JPD_gsOwS3pb6p5r_aCAizsweyemc4no-EKbx-3iFQ@HIDDEN>
<86ikn9opda.fsf@HIDDEN>
<CALG+76fWNn0ZySae+k7uh+f_eSX7D+MiEVYEqWTXW6YCw39L1g@HIDDEN>
<861ptwmuwl.fsf@HIDDEN>
In-Reply-To: <861ptwmuwl.fsf@HIDDEN>
From: =?UTF-8?Q?Bj=C3=B6rn_Lindqvist?= <bjourne@HIDDEN>
Date: Tue, 22 Apr 2025 01:55:20 +0200
X-Gm-Features: ATxdqUFcZecbMoCWJmLwqrLUDBZp2-Iuup4R5T6BdbgJxisYCePGwhhJ3w-9NmY
Message-ID: <CALG+76f-jdNPY==aCbG0AbCeMZZK1scYd1J2+9Atvgeumd_2Xg@HIDDEN>
Subject: Re: bug#77745: Async native compilation runs every time I start Emacs
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 77745
Cc: 77745 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
> We have a function for that, startup-redirect-eln-cache, and you are
> well advised to use that instead of constructing the list by hand.
> That function's doc string also says it's best to do that in
> early-init file, so that the list of directories is not changed
> halfway through the startup process, causing problems.
I tried doing exactly that. Here is the entirety of my early-init.el:
(startup-redirect-eln-cache (expand-file-name "~/.cache/emacs/eln"))
warnings, icons, and cl-lib are still being recompiled every time
Emacs starts. So it doesn't matter how I modify the cache path, the
result is still redundant recompilation.
> > The first sexp of my init.el is
> >
> > (setq user-emacs-directory "~/.config/emacs/lisp/")
> >
> > which is (?) executed *before* the native compiler kicks in.
> You cannot know that. Emacs executes quite a bit of code before it
> reads the init file, see startup.el.
No, but the native compiler is running asynchronously and is delayed
in relation to the modules loaded at startup. My guess is that it
schedules those modules for recompilation that it cannot find in its
load path but then, crucially, writes them to the new path it won't
look through the next time Emacs starts.
> The manual describes what happens by default, not what happens when
> you tinker with user-emacs-directory and/or native-comp-eln-load-path
> during the startup.
The same thing happens whether I directly modify the load path
or use startup-redirect-eln-cache.
I cut off the rest of your message because, while your advice is
appreciated, it is not about solving the bug. We can argue whether the
.eln files are cache data or not, but it is irrelevant. For those
users who want the eln-cache to reside in ~/.cache/emacs it should be
possible to do so, without causing any ill side-effects.
--=20
mvh/best regards Bj=C3=B6rn Lindqvist
bug-gnu-emacs@HIDDEN:bug#77745; Package emacs.
Full text available.Received: (at 77745) by debbugs.gnu.org; 21 Apr 2025 23:18:55 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 21 19:18:54 2025 Received: from localhost ([127.0.0.1]:40816 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u70Pd-0007fU-HC for submit <at> debbugs.gnu.org; Mon, 21 Apr 2025 19:18:54 -0400 Received: from mail-ua1-x931.google.com ([2607:f8b0:4864:20::931]:51215) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <bjourne@HIDDEN>) id 1u70Pa-0007ej-Db for 77745 <at> debbugs.gnu.org; Mon, 21 Apr 2025 19:18:51 -0400 Received: by mail-ua1-x931.google.com with SMTP id a1e0cc1a2514c-86b9ea43955so1542870241.2 for <77745 <at> debbugs.gnu.org>; Mon, 21 Apr 2025 16:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745277524; x=1745882324; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=PpQs+l2c7ktoUV+gVPASKZ9YJsjMbqAshyZNHP+lH0M=; b=kbe5qLY5+f2bkFNB8ahOfJkUZ5ohDQF2RkpB8RUGok+9EKymLhNRJMNY2l4F9jLPUB zCA/yvyADlxN+R4MTdCLqMU69sgXAw5qnRCRuQJiQtPF5zeATzMIGOzku8nCedVy4dgn qaCz5UwfegvzZDoIrM2Um4g/EToyTT7lR8VWtagkxEv+kqDCKCYY04W5xpv1/2IhxAyA mkeOXOpBhoJS0c1tpNoUf38X0RXrT1gLiP/ejq60vVfRI9zgQxQoiG/SStGU1L98Q8Hz /ArwJ6qRi9YrRmW9kk5YW0WYf2rqaTq49ElztvhpErFB/UicG4a5eiX4ZkpAxKV+PXd4 JlEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745277524; x=1745882324; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PpQs+l2c7ktoUV+gVPASKZ9YJsjMbqAshyZNHP+lH0M=; b=F/+KI1zAOD+nsr6gy7g8rjYG9VBREhXWdUpC+p60SAlaBMPOhWoieEGVdmPD0QfGEl SvBEkdCGhkonzhkwTLraMbSZS+NE2/lA7qQbtLm4QjJGotCc+OYUIdfesMxrkYO+san/ 2SKsosab/8+IAQYk7MyBE+SbO177YtwN/dqDwY/QDtMwZrD1bsruSregmqObjQcRymmg xlKjsqZ6P3jWuNduW9mU0LTClnX+Y80ZVcli7eh5s0/l41B6Oi1kf5PyxRCkiPqk9iFF kavRokHvT7Caw7JV1tAASw/32xSDi5iDqOKF45yGIJ5fcGiop2Pp+ah6VlSJQ3WTnlcv pNKQ== X-Forwarded-Encrypted: i=1; AJvYcCXMCX0T6oofHmYRFZxn9P0Ve1v6o9+mEqSi9WfW0Of0CcbJALgjxa5VWHZ6KmNV9QoydDf3Aw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzqAIYWpItXeWarr1t18L3m5SiStVZ0d9bLaKYQzcmb41NYZkLG Hbc7oExm2YJ5jK9kZoI3WAfi1NQMv/PcB6urIs3tYakuQrivCcAxF9NKowcSaRRd35+vXCv7/1F vkrVY2vKZv3KHpZJFn8iyWqIAd8M= X-Gm-Gg: ASbGncsyg5NJ8A8N/pZ9q6nDeJoec6gAxDwsE38dlyrqnZtrEbHPFNrryuVshp42gDp 1psNfDftYMfFTzupYYtC9iFOkCmkLpY/E1jej27SH8tcJg1LhFvfxYA== X-Google-Smtp-Source: AGHT+IEFLMxZ0bON+PZcOOvKfbpWonWZSWob530stb4qg3YwpSB0tzpsdyq77it0QHUE9UCsNQfzCc7I0HZPbyumR+I= X-Received: by 2002:a05:6102:55cd:b0:4c1:8e07:40b8 with SMTP id ada2fe7eead31-4cb800d86acmr6473205137.6.1745277524504; Mon, 21 Apr 2025 16:18:44 -0700 (PDT) MIME-Version: 1.0 References: <CALG+76edL6PRmODyibLDtAk6_cAy2a4JZ6dV4mRGhRO1h-WwNA@HIDDEN> <86r01yoe8y.fsf@HIDDEN> <CALG+76fvOrn_7cRnj4PJ09-1Jsowq9iS59xeEPS0Yi2BK=ac8A@HIDDEN> <86jz7qo6pk.fsf@HIDDEN> <CALG+76d+JPD_gsOwS3pb6p5r_aCAizsweyemc4no-EKbx-3iFQ@HIDDEN> <86ikn9opda.fsf@HIDDEN> <CALG+76fWNn0ZySae+k7uh+f_eSX7D+MiEVYEqWTXW6YCw39L1g@HIDDEN> <CAN+1HboLzkhcX=16ZUUUj2R5or46AfJjAqoxvQ5Yf9RMXa=7jQ@HIDDEN> <CALG+76eKm0h-2OXvEnVBz8EBA95vf66MWsUgazRwcKZMOfmJ5Q@HIDDEN> <CAN+1Hbp=1Xg87Xa6GjZ4_QL8T3DSHpjYh2qYYNB=m0ZQ0oyf8Q@HIDDEN> <CALG+76dTqO=1zXv=TC3s=VYmN2wrSW-NDnwqKkoELUqN8_-a6w@HIDDEN> <CAN+1HbrKV9SAoC+3-TFHB-Sc321F=-BOJjMBwG7JwgWcBwttrw@HIDDEN> In-Reply-To: <CAN+1HbrKV9SAoC+3-TFHB-Sc321F=-BOJjMBwG7JwgWcBwttrw@HIDDEN> From: =?UTF-8?Q?Bj=C3=B6rn_Lindqvist?= <bjourne@HIDDEN> Date: Tue, 22 Apr 2025 01:17:00 +0200 X-Gm-Features: ATxdqUEkdaVMsYAJbgzYBrihxrK_kvRjZGFO6Ii393fg3j-IJvhv3WmgijCT2bM Message-ID: <CALG+76ePO8+kj-ed9bUCub_=o7knb0chMD+bGKv8w_XXmiLO8g@HIDDEN> Subject: Re: bug#77745: Async native compilation runs every time I start Emacs To: Ship Mints <shipmints@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77745 Cc: Eli Zaretskii <eliz@HIDDEN>, 77745 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hello again, I've had some more time to debug now. > If your build completed successfully, and your installation is > correct, the aot eln files for icons and cl-lib should be in the > installed native directory and found there along with the others. > Are they installed correctly with correct file permissions? What > makes these two different than the other aot files? If I build from source with --with-native-compilation=3Daot then those modules are natively compiled and installed. Otherwise they are not. In the Arch Linux package of Emacs that I was using they were missing. Afact, not natively compiling during compilation shouldn't cause any issues. But it somehow does since cl-lib, icons, and warnings appear to be loaded before early-init.el. So if you change the path the native compiler uses for caching in early-init.el it will recompile these files every time you start Emacs. Btw, the --with-native-compilation option is a bit weird. Shouldn't there be two options, one for whether you want to compile Emacs with native compilation support and another one for whether you want to precompile all Elisp modules? --=20 mvh/best regards Bj=C3=B6rn Lindqvist
bug-gnu-emacs@HIDDEN:bug#77745; Package emacs.
Full text available.Received: (at 77745) by debbugs.gnu.org; 14 Apr 2025 11:22:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 14 07:22:16 2025 Received: from localhost ([127.0.0.1]:46051 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u4HtH-0003Cs-Tu for submit <at> debbugs.gnu.org; Mon, 14 Apr 2025 07:22:16 -0400 Received: from mail-ua1-x92c.google.com ([2607:f8b0:4864:20::92c]:54275) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <shipmints@HIDDEN>) id 1u4HtE-0003CZ-9I for 77745 <at> debbugs.gnu.org; Mon, 14 Apr 2025 07:22:12 -0400 Received: by mail-ua1-x92c.google.com with SMTP id a1e0cc1a2514c-86cce5dac90so1767519241.0 for <77745 <at> debbugs.gnu.org>; Mon, 14 Apr 2025 04:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744629726; x=1745234526; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=odwmU/alFnbDGTGtq2bJfKdeDufWpygjIRTarhRzsZI=; b=ZMV1XnukfytLRNT9erW7KGPxlz9uBsP7DnmibmKplVHPeuv6uCdg2I6sh+oSOxwlk6 Hjkx94TP5/Y7Kzy8mJjwVhlW+emRcDF+Nrixrb6eKh6FfKhxrY2JE74tFgh0VcWEQ++s fYVeAlBAIfPOP9V3w0/naNvfxsDu1Uz7AwoHBb6mmmz7ZQ52DRd71Zfnz+RFq4mvm6JK fHLyq9cqZngf/LYP8QittBZxpZqkldClr8jwZ4JAGmh7NsuuSI3le/BYx6pQnmYA2qLc 05zxIiOBLbpxba6CtQhopI6XT++MzBsy8m5D9lCiTC/MkbAuFfvnk3w1NE7ZZNhalKIS cpYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744629726; x=1745234526; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=odwmU/alFnbDGTGtq2bJfKdeDufWpygjIRTarhRzsZI=; b=df146DG+IM9YSefSMkwZ9VBB8YlxvSFYBpZjTfeOWStR+JgtIc+db4RGAJxDL30tKm zXictlmCqDHzF5OoWQmH6om+PVqc4/RJSosNVvjuAnIxvar1B1QZI12Yt14lkEmVhVng kbMLhZ7RVbwiowxdaYgoiluZGP9z8TTbjsfYiGyJ1a1eXchk1UPF8ecW9DsT7+HNGz5a Gi9OE7s8LHfVcsbxwAPS3mVbk1Sx8n3CRt0Lc8FajaZV1ZME9U83z36+JuCJsf9OS9Sz dgHA3uYkIv65nNXE6PIr6HWhSJlDDUnFis0Jm2Tv9/mKF8ypmmumyNdnJSwK3IKd95To fSfw== X-Forwarded-Encrypted: i=1; AJvYcCXhMYSadZ96vZ5Jg3K1D8As5wPJzZwY79reIUCL5aNljZsE/he0yKW+ODEmyu0jQGpsL3cYWQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0Ywxzgi2lQmOlKQGY6Wiqd0+33Myok4vjPD2TCRZrIygDqiTKIGe camyO3LY7YaYVEa293MmQ7S07nfs8hTtl/AX8aTL4wkoLf/sPfCdmL6QKjD2JELx7RUEiWNXwJ2 wv9bwRrzQkZpFtD7uPzzcf4Zl944= X-Gm-Gg: ASbGnctUGu7hGzCGl4Sk2UxVjODdiEClpjUpe9egm7DLnpfWCP3IGT6uxM8fF9ANYGP S8XHqyMcU0d4PKLEqrrt5R8rAHJR6t/D2zth7rAmvHweBWI+wgGZJMYITcrw8d4TuxI5EiK38wz Ro8ylADCi4anSgvwFT2dfmrA== X-Google-Smtp-Source: AGHT+IEktVc2uFCRtLRFGQurz0Lc3LKd2RhF13TfP600+nYF1ZETEyq3rKrRjWG0X8liTYOTVmE3mpN1ocUzePZL0T8= X-Received: by 2002:a05:6102:dce:b0:4c3:7f7:92f4 with SMTP id ada2fe7eead31-4c9e4ee6b5amr6700381137.6.1744629726312; Mon, 14 Apr 2025 04:22:06 -0700 (PDT) MIME-Version: 1.0 References: <CALG+76edL6PRmODyibLDtAk6_cAy2a4JZ6dV4mRGhRO1h-WwNA@HIDDEN> <86r01yoe8y.fsf@HIDDEN> <CALG+76fvOrn_7cRnj4PJ09-1Jsowq9iS59xeEPS0Yi2BK=ac8A@HIDDEN> <86jz7qo6pk.fsf@HIDDEN> <CALG+76d+JPD_gsOwS3pb6p5r_aCAizsweyemc4no-EKbx-3iFQ@HIDDEN> <86ikn9opda.fsf@HIDDEN> <CALG+76fWNn0ZySae+k7uh+f_eSX7D+MiEVYEqWTXW6YCw39L1g@HIDDEN> <CAN+1HboLzkhcX=16ZUUUj2R5or46AfJjAqoxvQ5Yf9RMXa=7jQ@HIDDEN> <CALG+76eKm0h-2OXvEnVBz8EBA95vf66MWsUgazRwcKZMOfmJ5Q@HIDDEN> <CAN+1Hbp=1Xg87Xa6GjZ4_QL8T3DSHpjYh2qYYNB=m0ZQ0oyf8Q@HIDDEN> <CALG+76dTqO=1zXv=TC3s=VYmN2wrSW-NDnwqKkoELUqN8_-a6w@HIDDEN> In-Reply-To: <CALG+76dTqO=1zXv=TC3s=VYmN2wrSW-NDnwqKkoELUqN8_-a6w@HIDDEN> From: Ship Mints <shipmints@HIDDEN> Date: Mon, 14 Apr 2025 07:21:55 -0400 X-Gm-Features: ATxdqUG58r7LgAK4cYv4_QV05sBC-LB55wgDY-DG-5bFkZDb_GKRqj5m69gWhWM Message-ID: <CAN+1HbrKV9SAoC+3-TFHB-Sc321F=-BOJjMBwG7JwgWcBwttrw@HIDDEN> Subject: Re: bug#77745: Async native compilation runs every time I start Emacs To: =?UTF-8?Q?Bj=C3=B6rn_Lindqvist?= <bjourne@HIDDEN> Content-Type: multipart/alternative; boundary="0000000000001a009f0632bb43b6" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77745 Cc: Eli Zaretskii <eliz@HIDDEN>, 77745 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --0000000000001a009f0632bb43b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Apr 14, 2025 at 6:14=E2=80=AFAM Bj=C3=B6rn Lindqvist <bjourne@gmail= .com> wrote: > > Of course. But you run the risk of incompatibilities later on. > > I guess, but there is no indication in the manual that > native-comp-eln-load-path shouldn't be modified directly. Emacs has many > other variables for search paths (like load-path) which can be freely > modified. And what if you want to add multiple directories to > native-comp-eln-load-path? Then startup-redirect-eln-cache is not > sufficient. > > > I apologize that I missed what you're trying to accomplish. If you > > want to avoid compiler warnings, perhaps suppress warnings in early > > init, and then reenable them in init where it makes sense if you > > want warnings for external packages but not core packages? > > No, what I want to accomplish is: > > 1. Compilation cache in ~/.cache/emacs/eln, > 2. No redundant recompilations at startup. > > > The load logic is, I think, find the elc file (or make it, if byte > > compilation isn't inhibited) along load-path, and if found, probe > > the eln cache and swap the eln, if found. > > I think so too, but there appears to be a race condition > involved. First the compiler can't find foobar.eln on the > native-comp-eln-load-path, so it schedules it for > recompilation. Meanwhile, native-comp-eln-load-path is updated. Then > the compiler writes foobar.eln to the *new path*. > > > What platform are you on and does your build have icons and cl-lib > > in its pre-compiled directory? Are you building Emacs without aot? > > I'm building Emacs with aot on Arch Linux. Recompilation happens in > both Emacs 30.1 and 31.0.50. icons, cl-lib, and warnings are not in > the system-wide /opt/emacs/lib/emacs/31.0.50/native-lisp/ directory. > If your build completed successfully, and your installation is correct, the aot eln files for icons and cl-lib should be in the installed native directory and found there along with the others. Are they installed correctly with correct file permissions? What makes these two different than the other aot files? --0000000000001a009f0632bb43b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:monospace"><span style=3D"font-family:Arial,Helvetica,sans-serif">= On Mon, Apr 14, 2025 at 6:14=E2=80=AFAM Bj=C3=B6rn Lindqvist <<a href=3D= "mailto:bjourne@HIDDEN">bjourne@HIDDEN</a>> wrote:</span></div></d= iv><div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D"gm= ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,= 204,204);padding-left:1ex">> Of course.=C2=A0 But you run the risk of in= compatibilities later on.<br> <br> I guess, but there is no indication in the manual that<br> native-comp-eln-load-path shouldn't be modified directly. Emacs has man= y<br> other variables for search paths (like load-path) which can be freely<br> modified. And what if you want to add multiple directories to<br> native-comp-eln-load-path? Then startup-redirect-eln-cache is not<br> sufficient.<br> <br> > I apologize that I missed what you're trying to accomplish.=C2=A0 = If you<br> > want to avoid compiler warnings, perhaps suppress warnings in early<br= > > init, and then reenable them in init where it makes sense if you<br> > want warnings for external packages but not core packages?<br> <br> No, what I want to accomplish is:<br> <br> =C2=A0 =C2=A0 1. Compilation cache in ~/.cache/emacs/eln,<br> =C2=A0 =C2=A0 2. No redundant recompilations at startup.<br> <br> > The load logic is, I think, find the elc file (or make it, if byte<br> > compilation isn't inhibited) along load-path, and if found, probe<= br> > the eln cache and swap the eln, if found.<br> <br> I think so too, but there appears to be a race condition<br> involved. First the compiler can't find foobar.eln on the<br> native-comp-eln-load-path, so it schedules it for<br> recompilation. Meanwhile, native-comp-eln-load-path is updated. Then<br> the compiler writes foobar.eln to the *new path*.<br> <br> > What platform are you on and does your build have icons and cl-lib<br> > in its pre-compiled directory?=C2=A0 Are you building Emacs without ao= t?<br> <br> I'm building Emacs with aot on Arch Linux. Recompilation happens in<br> both Emacs 30.1 and 31.0.50. icons, cl-lib, and warnings are not in<br> the system-wide /opt/emacs/lib/emacs/31.0.50/native-lisp/ directory.<br></b= lockquote><div><br></div><div class=3D"gmail_default" style=3D"font-family:= monospace">If your build completed successfully, and your installation is c= orrect, the aot eln files for icons and cl-lib should be in the installed n= ative directory and found there along with the others.=C2=A0 Are they insta= lled correctly with correct file permissions?=C2=A0 What makes these two di= fferent than the other aot files?</div></div></div> --0000000000001a009f0632bb43b6--
bug-gnu-emacs@HIDDEN:bug#77745; Package emacs.
Full text available.Received: (at 77745) by debbugs.gnu.org; 14 Apr 2025 10:39:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 14 06:39:29 2025 Received: from localhost ([127.0.0.1]:45959 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u4HDs-000158-Qc for submit <at> debbugs.gnu.org; Mon, 14 Apr 2025 06:39:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42592) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1u4HDp-00014r-Qw for 77745 <at> debbugs.gnu.org; Mon, 14 Apr 2025 06:39:26 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1u4HDk-0006FG-Hi; Mon, 14 Apr 2025 06:39:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=pENBW59cAZ4ASsDQ5hA+/Myx/69al2C4mr86PgSJF+4=; b=mBi6JFpIAVq2UVq8G5F4 6Ii5fWPnVrp5Kbizf+vy89onNamG/4gpnmhXRSBHoK+LtV8tRfGUpP5sVzyyNH1ruw7wzEtELLUCs LY9oipZItV3ZQnvU2JMNjC4lEw0l8By58T4aj6AE0RB9GVpAKsWVnBaj1AblhIWRxD1rAnfTGkM5y k2EYFhG/6pqCQB/EoHELTI8pGB35Y+fqnhRNk7BHBzSFWRQvyQwyvxJu2UqHZPNzpQNkFz/prE2pp bt38NImEK4JIxezTS7z8JNAYBosmrUz0ha4dInKSvnTVkbXEbkFRZD7LtAHDX9xkf0oAdI2jKoDwx ifviQDSR6O3wnA==; Date: Mon, 14 Apr 2025 13:39:18 +0300 Message-Id: <86tt6rhvs9.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?utf-8?Q?Bj=C3=B6rn?= Lindqvist <bjourne@HIDDEN> In-Reply-To: <CALG+76dTqO=1zXv=TC3s=VYmN2wrSW-NDnwqKkoELUqN8_-a6w@HIDDEN> (message from =?utf-8?Q?Bj=C3=B6rn?= Lindqvist on Mon, 14 Apr 2025 12:14:13 +0200) Subject: Re: bug#77745: Async native compilation runs every time I start Emacs References: <CALG+76edL6PRmODyibLDtAk6_cAy2a4JZ6dV4mRGhRO1h-WwNA@HIDDEN> <86r01yoe8y.fsf@HIDDEN> <CALG+76fvOrn_7cRnj4PJ09-1Jsowq9iS59xeEPS0Yi2BK=ac8A@HIDDEN> <86jz7qo6pk.fsf@HIDDEN> <CALG+76d+JPD_gsOwS3pb6p5r_aCAizsweyemc4no-EKbx-3iFQ@HIDDEN> <86ikn9opda.fsf@HIDDEN> <CALG+76fWNn0ZySae+k7uh+f_eSX7D+MiEVYEqWTXW6YCw39L1g@HIDDEN> <CAN+1HboLzkhcX=16ZUUUj2R5or46AfJjAqoxvQ5Yf9RMXa=7jQ@HIDDEN> <CALG+76eKm0h-2OXvEnVBz8EBA95vf66MWsUgazRwcKZMOfmJ5Q@HIDDEN> <CAN+1Hbp=1Xg87Xa6GjZ4_QL8T3DSHpjYh2qYYNB=m0ZQ0oyf8Q@HIDDEN> <CALG+76dTqO=1zXv=TC3s=VYmN2wrSW-NDnwqKkoELUqN8_-a6w@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77745 Cc: shipmints@HIDDEN, 77745 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Björn Lindqvist <bjourne@HIDDEN> > Date: Mon, 14 Apr 2025 12:14:13 +0200 > Cc: Eli Zaretskii <eliz@HIDDEN>, 77745 <at> debbugs.gnu.org > > > Of course. But you run the risk of incompatibilities later on. > > I guess, but there is no indication in the manual that > native-comp-eln-load-path shouldn't be modified directly. Emacs has many > other variables for search paths (like load-path) which can be freely > modified. And what if you want to add multiple directories to > native-comp-eln-load-path? Then startup-redirect-eln-cache is not > sufficient. Adding directories is okay, as long as you keep this requirement from the doc string fulfilled: The last directory of this list is assumed to be the one holding the system *.eln files, which are the files produced when building Emacs.
bug-gnu-emacs@HIDDEN:bug#77745; Package emacs.
Full text available.
Received: (at 77745) by debbugs.gnu.org; 14 Apr 2025 10:14:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 14 06:14:33 2025
Received: from localhost ([127.0.0.1]:45884 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u4Gpl-0008GR-6l
for submit <at> debbugs.gnu.org; Mon, 14 Apr 2025 06:14:33 -0400
Received: from mail-ua1-x92c.google.com ([2607:f8b0:4864:20::92c]:58587)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <bjourne@HIDDEN>) id 1u4Gpj-0008GC-Fo
for 77745 <at> debbugs.gnu.org; Mon, 14 Apr 2025 06:14:32 -0400
Received: by mail-ua1-x92c.google.com with SMTP id
a1e0cc1a2514c-86d3907524cso1641433241.0
for <77745 <at> debbugs.gnu.org>; Mon, 14 Apr 2025 03:14:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1744625665; x=1745230465; darn=debbugs.gnu.org;
h=content-transfer-encoding:cc:to:subject:message-id:date:from
:in-reply-to:references:mime-version:from:to:cc:subject:date
:message-id:reply-to;
bh=Bhyt7bC8o4fsVP3OYuaMtzHoijFneUOUcs94oC+yPzM=;
b=EDG0IWrDbJHAcdFuMS6bgo/07a5MtwQsoGji9/twaWdIYKri4V7w2ks9HIZ+JtyyJp
1NRKHPrT30IW3QJn/ZtYYqzd7E/2A0i41nIpGlwxdQIhcyXSODQMX4H4Eiwvj+2cNv3T
mn+Cd25w+ZeLSa0UzG4z39Z7HrFF5LauUawWpXCfFWYBOUPBKHIhQkh1RkR7Y79ddS0y
t/75dIq7Ku5klUhc2QfImFqPUjacpng4ufHTIcPwdEeHIC9jb3rsUpGDBn4JXFd8s754
sEiV90eiO+BF1pHdpYERUZsi9iLrVRj53k8jU2iEFSJ5lZp47JCuwYZowlixHVfIHZW7
c1xg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1744625665; x=1745230465;
h=content-transfer-encoding:cc:to:subject:message-id:date:from
:in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=Bhyt7bC8o4fsVP3OYuaMtzHoijFneUOUcs94oC+yPzM=;
b=Fvrc00Sapv2PHKji6i7WmSGwA/i72rm7Z9JeaDdwfjarVDigKgo1kPkjqngI0a6Ovt
Szgw/EXVWPA4a9ZGWXi5DlcPdlZf5xtswMMF2/tFx7U1Xnl+ixZ7imBBCpdtxJY9gk6H
ZJkbUQ/6nhJYjy5Himn2jWDbD1lUjYAgoOvvam9eFWVLMVZ7d0t5BoV/wmnmymHnhzF7
Zf4S7LBE5UdzKK1gGhtyDXilRa7YZUozriOkbzykaib3H8OxG+BVyaW3o8N9R9sOazCf
5QyQaJVMaXwhuetlcW0UOYhtoRzTGNDhpH6urkOgIqDBL+sjsbGFvMtQaxxW8y7/7HSd
D3zQ==
X-Forwarded-Encrypted: i=1;
AJvYcCVOak/hil1fs7LPXZL1+x5hyd0NdtJvmkNTH7ute0NyoRsLzmi7e/PbTm4NJu6qC2iVvvy7/g==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Ywz0MM/TGSdr6hWkeZ0yV2q175Pg1A8dGO3VnSJmz/6dH04MamU
4EI+rSX9jMIlsFnQvVFh5Ji5/LBCmQyoILPYYQrzU55InD8K9sHBp9B5ylqV0VTPeSNtGkmu9xd
6vnoH2ulGx+Evv/lk6i/ZrOgkIao=
X-Gm-Gg: ASbGnctZPNKgotatLWOq8iFhkcFG/65JnjYY4boLpO65N2b6IOpwA7oqvkgUJIkRU41
6jgqKE6z6lXmW1BdzL8mh58oT6ZfIk6hm1tEB6hkNCOGOecXv7Hi502qOpTdVJsuMCiZlP90CQe
ouH34YE6yAQj2MPqCUWVjEh05XuziExENqoTQOxrq3yGSZ1qzMxQ==
X-Google-Smtp-Source: AGHT+IF+6wQ/tp2g5aJsIXvxl9JeK66d6Wmr0pdZxS2uUMcPHEiA2x+mxjqy2hVfY42AlcnySI6tpvMglvVcdX6rxDQ=
X-Received: by 2002:a05:6102:3a11:b0:4c1:924e:1a1d with SMTP id
ada2fe7eead31-4c9e4fffa7dmr7523055137.18.1744625665424; Mon, 14 Apr 2025
03:14:25 -0700 (PDT)
MIME-Version: 1.0
References: <CALG+76edL6PRmODyibLDtAk6_cAy2a4JZ6dV4mRGhRO1h-WwNA@HIDDEN>
<86r01yoe8y.fsf@HIDDEN>
<CALG+76fvOrn_7cRnj4PJ09-1Jsowq9iS59xeEPS0Yi2BK=ac8A@HIDDEN>
<86jz7qo6pk.fsf@HIDDEN>
<CALG+76d+JPD_gsOwS3pb6p5r_aCAizsweyemc4no-EKbx-3iFQ@HIDDEN>
<86ikn9opda.fsf@HIDDEN>
<CALG+76fWNn0ZySae+k7uh+f_eSX7D+MiEVYEqWTXW6YCw39L1g@HIDDEN>
<CAN+1HboLzkhcX=16ZUUUj2R5or46AfJjAqoxvQ5Yf9RMXa=7jQ@HIDDEN>
<CALG+76eKm0h-2OXvEnVBz8EBA95vf66MWsUgazRwcKZMOfmJ5Q@HIDDEN>
<CAN+1Hbp=1Xg87Xa6GjZ4_QL8T3DSHpjYh2qYYNB=m0ZQ0oyf8Q@HIDDEN>
In-Reply-To: <CAN+1Hbp=1Xg87Xa6GjZ4_QL8T3DSHpjYh2qYYNB=m0ZQ0oyf8Q@HIDDEN>
From: =?UTF-8?Q?Bj=C3=B6rn_Lindqvist?= <bjourne@HIDDEN>
Date: Mon, 14 Apr 2025 12:14:13 +0200
X-Gm-Features: ATxdqUGr6WRpJibP865HXZ_3ZKnxKsMrdPSAkhFmJBgtKXGpmWVIPGk_TxVnR3g
Message-ID: <CALG+76dTqO=1zXv=TC3s=VYmN2wrSW-NDnwqKkoELUqN8_-a6w@HIDDEN>
Subject: Re: bug#77745: Async native compilation runs every time I start Emacs
To: Ship Mints <shipmints@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 77745
Cc: Eli Zaretskii <eliz@HIDDEN>, 77745 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
> Of course. But you run the risk of incompatibilities later on.
I guess, but there is no indication in the manual that
native-comp-eln-load-path shouldn't be modified directly. Emacs has many
other variables for search paths (like load-path) which can be freely
modified. And what if you want to add multiple directories to
native-comp-eln-load-path? Then startup-redirect-eln-cache is not
sufficient.
> I apologize that I missed what you're trying to accomplish. If you
> want to avoid compiler warnings, perhaps suppress warnings in early
> init, and then reenable them in init where it makes sense if you
> want warnings for external packages but not core packages?
No, what I want to accomplish is:
1. Compilation cache in ~/.cache/emacs/eln,
2. No redundant recompilations at startup.
> The load logic is, I think, find the elc file (or make it, if byte
> compilation isn't inhibited) along load-path, and if found, probe
> the eln cache and swap the eln, if found.
I think so too, but there appears to be a race condition
involved. First the compiler can't find foobar.eln on the
native-comp-eln-load-path, so it schedules it for
recompilation. Meanwhile, native-comp-eln-load-path is updated. Then
the compiler writes foobar.eln to the *new path*.
> What platform are you on and does your build have icons and cl-lib
> in its pre-compiled directory? Are you building Emacs without aot?
I'm building Emacs with aot on Arch Linux. Recompilation happens in
both Emacs 30.1 and 31.0.50. icons, cl-lib, and warnings are not in
the system-wide /opt/emacs/lib/emacs/31.0.50/native-lisp/ directory.
--=20
mvh/best regards Bj=C3=B6rn Lindqvist
bug-gnu-emacs@HIDDEN:bug#77745; Package emacs.
Full text available.Received: (at 77745) by debbugs.gnu.org; 13 Apr 2025 06:47:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 13 02:47:34 2025 Received: from localhost ([127.0.0.1]:37808 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u3r7r-0004F0-Q9 for submit <at> debbugs.gnu.org; Sun, 13 Apr 2025 02:47:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47116) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1u3r7p-0004Dr-D3 for 77745 <at> debbugs.gnu.org; Sun, 13 Apr 2025 02:47:30 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1u3r7k-0006Ab-0k; Sun, 13 Apr 2025 02:47:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=/vTDe1+Kl+eDYvGYH1jGqjLWf6C/bkDbu9pBp8H3/4E=; b=WuTCky11yfQAjkj4eE4w m3Ula8wsTs/BH2t266ubWTXW5hDkU9bt+donMLi8mIZ9wBaLG/07d/6MJpP+oL7bEttG8uPvlb5J6 C5Qw564+IRWyJcEYtTnT6CvGg9IcHYPzzYTDlqQsaISv4ZMNMdYwxhbDTDwVY/A2MADyf6bGOH9Lu zhzLyq/ucDIIjT5Ds1bNDugc3aaVLGpVRLeMHoqVnuL4DYefH7fLNda1b67AC3rdoHaUz6rKHdHy+ A2jbRA0ByP4/Pa256RNLMFbp2sHFNYi/HDg7Equi2/zjpP7Fyf5xk9UpT5laNoKC3/1h8ReVmtDik +KOu05Qck8MDTw==; Date: Sun, 13 Apr 2025 09:47:19 +0300 Message-Id: <86zfgklfrc.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?utf-8?Q?Bj=C3=B6rn?= Lindqvist <bjourne@HIDDEN> In-Reply-To: <CALG+76eKm0h-2OXvEnVBz8EBA95vf66MWsUgazRwcKZMOfmJ5Q@HIDDEN> (message from =?utf-8?Q?Bj=C3=B6rn?= Lindqvist on Sat, 12 Apr 2025 20:14:50 +0200) Subject: Re: bug#77745: Async native compilation runs every time I start Emacs References: <CALG+76edL6PRmODyibLDtAk6_cAy2a4JZ6dV4mRGhRO1h-WwNA@HIDDEN> <86r01yoe8y.fsf@HIDDEN> <CALG+76fvOrn_7cRnj4PJ09-1Jsowq9iS59xeEPS0Yi2BK=ac8A@HIDDEN> <86jz7qo6pk.fsf@HIDDEN> <CALG+76d+JPD_gsOwS3pb6p5r_aCAizsweyemc4no-EKbx-3iFQ@HIDDEN> <86ikn9opda.fsf@HIDDEN> <CALG+76fWNn0ZySae+k7uh+f_eSX7D+MiEVYEqWTXW6YCw39L1g@HIDDEN> <CAN+1HboLzkhcX=16ZUUUj2R5or46AfJjAqoxvQ5Yf9RMXa=7jQ@HIDDEN> <CALG+76eKm0h-2OXvEnVBz8EBA95vf66MWsUgazRwcKZMOfmJ5Q@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77745 Cc: shipmints@HIDDEN, 77745 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Björn Lindqvist <bjourne@HIDDEN> > Date: Sat, 12 Apr 2025 20:14:50 +0200 > Cc: Eli Zaretskii <eliz@HIDDEN>, 77745 <at> debbugs.gnu.org > > > setq is incorrect for overriding native-comp-eln-load-path. Call startup-redirect-eln-cache only in your early-init.el file. > > > > As far as overriding user-emacs-directory is concerned, for best results you should use the --init-directory command-line argument if you can't live with the default. The default does respect XDG_CONFIG_HOME and defaults to XDG_CONFIG_HOME/emacs or ~/.config/emacs then the more traditional locations, in that priority. This assumes you do not specify --user. If you don't use this method, you'll have to do a census of the variables dependent on user-emacs-directory and fix them all. There currently is no function that does that, and even if there were, if you ran it too late in your startup cycle, external packages would be tainted with the old value. > > The manual says that you can modify native-comp-eln-load-path directly: > > Sometimes there could be a need to prevent the native compilation > from writing its results, the *.eln files, into a subdirectory of > user-emacs-directory (see The Init File). You can do that by > either changing the value of native-comp-eln-load-path (see > Native-Compilation Variables) or by temporarily pointing the HOME > environment variable to a non-existing directory. That fragment explains how to _prevent_ native-compilation, by changing the eln load path so it is basically invalid. So your reference to that as a justification for manually changing the value is misguided. > Regardless, it doesn't matter. Having > > (startup-redirect-eln-cache (expand-file-name "~/.cache/emacs/eln/")) > > in early-init.el is exactly equivalent to having > > (setq native-comp-eln-load-path > (list (expand-file-name "~/tmp/") > "/opt/emacs/lib/emacs/31.0.50/native-lisp/")) > > in init.el. Only if your original value had only two elements in the list. If it has more, the above will lose some elements. And anyway, it could be equivalent today, but it might not be equivalent tomorrow, if we decide something else is needed. Using public APIs makes your code future-proof, while doing the stuff by hand requires you to adjust to any future changes, and on top of that requires you to understand very well how the eln load path is used. Why do all that when we already provide a public function whose use avoids all of that? > The native compiler correctly reads and writes most files > in ~/.cache/emacs/eln/ *except* for warnings-28e75f4d-f0ade81c.eln, > icons-eafe82eb-47a1ab50.eln, and cl-lib-8b938900-6d6e9142.eln which it > keeps recompiling every time I start emacs. Probably because something in your startup triggers delayed warnings very early, and with eln load path modified halfway through the startup, the compiled *.eln files for these two packages are not found. > The only way I've found to get it to not recompile warnings, icons, > and cl-lib is to keep the default ~/.config/emacs/eln-cache path. Which is what you should do in the first place. You should in any case avoid removing that directory from the eln load path.
bug-gnu-emacs@HIDDEN:bug#77745; Package emacs.
Full text available.Received: (at 77745) by debbugs.gnu.org; 13 Apr 2025 06:35:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 13 02:35:04 2025 Received: from localhost ([127.0.0.1]:37778 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u3qvl-0001tE-EG for submit <at> debbugs.gnu.org; Sun, 13 Apr 2025 02:35:04 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53664) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1u3qvi-0001sT-Od for 77745 <at> debbugs.gnu.org; Sun, 13 Apr 2025 02:34:59 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1u3qvd-00049o-BH; Sun, 13 Apr 2025 02:34:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=OAtYzgxdgbJA9U+mVapnVIaaqEKpKauils26tlywO30=; b=e+SXg4gQutOzXfr+kXRQ z9q6y3AFkJ16310FO1a+W9iKr4bNxvlujkWFRj9Lxc5yDwWUIy3VjbC4VggXq6KRRbxJ7D5Td+ByN M4VMuj04fF1viO3HoreMg2RfW41/0iy+b741I0DIHliEheIFewDetvDXxkXbA9iRX3c5N17hkoeuR 0xBiqDt1iKPGLjSeKce1yZIfycP8oqxRb5keDqJNvisR5/kLEiDKtk68WeclLPpuxbsvZec6DXJax OWBJ7WHm6e5Aqg2ymH177UXZIZ9xyNc0vQeH7Q5MJw/qmR8HsWOTgi2pe4CWMrKN/DsA6ElRl6M91 0E/rC6RqfZY6Sw==; Date: Sun, 13 Apr 2025 09:34:50 +0300 Message-Id: <861ptwmuwl.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?utf-8?Q?Bj=C3=B6rn?= Lindqvist <bjourne@HIDDEN> In-Reply-To: <CALG+76fWNn0ZySae+k7uh+f_eSX7D+MiEVYEqWTXW6YCw39L1g@HIDDEN> (message from =?utf-8?Q?Bj=C3=B6rn?= Lindqvist on Sat, 12 Apr 2025 19:08:05 +0200) Subject: Re: bug#77745: Async native compilation runs every time I start Emacs References: <CALG+76edL6PRmODyibLDtAk6_cAy2a4JZ6dV4mRGhRO1h-WwNA@HIDDEN> <86r01yoe8y.fsf@HIDDEN> <CALG+76fvOrn_7cRnj4PJ09-1Jsowq9iS59xeEPS0Yi2BK=ac8A@HIDDEN> <86jz7qo6pk.fsf@HIDDEN> <CALG+76d+JPD_gsOwS3pb6p5r_aCAizsweyemc4no-EKbx-3iFQ@HIDDEN> <86ikn9opda.fsf@HIDDEN> <CALG+76fWNn0ZySae+k7uh+f_eSX7D+MiEVYEqWTXW6YCw39L1g@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77745 Cc: 77745 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Björn Lindqvist <bjourne@HIDDEN> > Date: Sat, 12 Apr 2025 19:08:05 +0200 > Cc: 77745 <at> debbugs.gnu.org > > Hello again, > > I tried setting native-comp-eln-load-path explicitly in init.el > > (setq native-comp-eln-load-path > (list (expand-file-name "~/tmp/") > "/opt/emacs/lib/emacs/31.0.50/native-lisp/")) > > and this works much better. The native compiler only > writes to ~/tmp/31.0.50-859de2ee/. Not in any directory under > ~/.config/emacs. Only the files warnings-28e75f4d-f0ade81c.eln, > icons-eafe82eb-47a1ab50.eln, and cl-lib-8b938900-6d6e9142.eln gets > recompiled on startup. We have a function for that, startup-redirect-eln-cache, and you are well advised to use that instead of constructing the list by hand. That function's doc string also says it's best to do that in early-init file, so that the list of directories is not changed halfway through the startup process, causing problems. Please be sure to follow our recommendations, since they are the best practices we decided upon based on analyzing the various use cases and issues whose subtleties you may not be aware of. > > What this means is that if your init files load packages, directly or > > indirectly, before they modify user-emacs-directory, the native > > compilation will start for those packages using the value of > > native-comp-eln-load-path that is not what your session will > > subsequently use. And packages compiled after user-emacs-directory is > > modified will have their *.eln files deposited in another directory. > > > IOW, the order in which you modify user-emacs-directory and load > > packages that need native compilation matters _a_lot_, as you have > > discovered. > > The first sexp of my init.el is > > (setq user-emacs-directory "~/.config/emacs/lisp/") > > which is (?) executed *before* the native compiler kicks in. You cannot know that. Emacs executes quite a bit of code before it reads the init file, see startup.el. Unless you really know that code through and through, you should be modifying the eln load path as early as possible, if at all. > What I think happens is that the native compiler builds the > native-comp-eln-load-path based on the value of user-emacs-directory > before init.el is loaded. That's not accurate. The startup code updates native-comp-eln-load-path no less than 3 times during the startup procedure, at certain strategic points, because various init files could affect it. Once again, the startup procedure, being a kind-of bootstrap process, is very complicated and delicate, and you are advised to use the functions and facilities it provides as we recommend using them, because doing stuff on your own can very easily break your sessions. > Then user-emacs-directory gets modified and > this changes the path it *writes* to, but does nothing to the paths it > *reads* from. There are no two paths, just one. It is used both for looking up *.eln files and for writing newly-compiled ones. > So it compiles the files and writes them to a directory > it won't read from the next time I start Emacs. Indeed, if I log > native-comp-eln-load-path I can see that the value is: > > (~/.config/emacs/eln-cache/ /opt/emacs/lib/emacs/31.0.50/native-lisp/) > > but the native compiler writes to ~/.config/emacs/lisp/eln-cache/ > (note: /lisp/), contradicting the manual: "By default, > asynchronous native compilation writes the *.eln files it produces to > a subdirectory of the first writable directory specified by the > native-comp-eln-load-path variable". The manual describes what happens by default, not what happens when you tinker with user-emacs-directory and/or native-comp-eln-load-path during the startup. Since you change user-emacs-directory halfway through, some of the compiled files get written to the wrong place, and are not found when they are needed upon the next startup. Just don't do that! > So it must be a bug that setting user-emacs-directory updates the path > the native compiler writes to, but not the path(s) it reads from. No, there's no bug. The only problem is that you are tinkering with this delicate process in ways that we don't support, and without a good understanding of what that does. > > We recommend not to modify the value of user-emacs-directory, > > because doing that might break various initializations Emacs > > performs during startup. > > Are there technical reasons user-emacs-directory can't be changed? I explained them in my last two messages. And it isn't that it could be modified, it's just that doing that "by hand" in the middle of the startup process can easily break things. As it did for you. The supported way of affecting the value of user-emacs-directory is to invoke Emacs with the --init-directory command-line option, but even that has its subtle aspects, described in the manual. That option was added for some rare and very specific use cases, and in general my advice it not to use even that unless really necessary. > Isn't code that relies on user-emacs-directory having a specific value > or to never change is buggy? Since the value of user-emacs-directory is determined by Emacs as part of the process of finding your init files, and since the value is thereafter used to find other related directories and files, it should be clear to you that modifying the value in arbitrary places during the startup is dangerous. You should only use the supported interfaces and protocols for adjusting it, and preferably not touch it at all. If you do, you are on your own; I'm not interested in complicating even more the already quite complex code in startup.el to cater to such use cases, when better, more reliable ways of doing the same already exist and are documented. > > The eln cache Emacs uses is not really a "cache" XDG spec had in mind. > > The *.eln files are not "non-essential", since we want them to > > persist, and removing that directory will make the next startup of > > Emacs significantly longer and more expensive. > > I think what you're describing is exactly what a cache does and > exactly how other programs use $XDG_CACHE_HOME. Of course a program > would take longer to start after you blow up its cache. This is not a cache. This is JIT-compiled code of demand-loaded Emacs packages. Removing it is the same as removing executable binaries and leaving the user with their source code, to be recompiled the next time it is needed. It is absurd to consider this a cache in the XDG meaning.
bug-gnu-emacs@HIDDEN:bug#77745; Package emacs.
Full text available.Received: (at 77745) by debbugs.gnu.org; 12 Apr 2025 18:50:01 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 12 14:50:01 2025 Received: from localhost ([127.0.0.1]:59547 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u3fvU-0001zK-O0 for submit <at> debbugs.gnu.org; Sat, 12 Apr 2025 14:50:01 -0400 Received: from mail-ua1-x92a.google.com ([2607:f8b0:4864:20::92a]:58720) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <shipmints@HIDDEN>) id 1u3fvS-0001yb-BS for 77745 <at> debbugs.gnu.org; Sat, 12 Apr 2025 14:49:59 -0400 Received: by mail-ua1-x92a.google.com with SMTP id a1e0cc1a2514c-86d6ac4d5a9so1283331241.1 for <77745 <at> debbugs.gnu.org>; Sat, 12 Apr 2025 11:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744483792; x=1745088592; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=19MSXYpsvUoHLavQ/gvWL7wwiBoXQLvebLr4y4qFgXo=; b=Uw8sM3c8RI2r82LA8INFBK/H633QmD10CwDWIMZJENDLND21rJROX2zYWn5UQf27Jy o4HqXVKZNP4jYJCckCJHFPEWkDd71r/5PEKYOOrPKQIxp6yzNRwPYqU/AWDgb8gRlZAb FIp0BCce9KOlLD+fNFVmRPIgtGbaNK4876PRi0Y3melrA4aV5pbWMUuR9qV07CcTalpD O5GD1ODde+HuBXaLFE/tEDLBtn9CcELm69NbfNsCQqn2h60GDvsZVEhX0eMaMURanN19 W5quzArmLP5JtOBqrF7OaW9kOCi0NNTgeAGkAH/3VqdXfwA63E1oyPnf6WooiNX+4wOC eNpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744483792; x=1745088592; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=19MSXYpsvUoHLavQ/gvWL7wwiBoXQLvebLr4y4qFgXo=; b=FIxLpc4Bl29TXF182GXzcO5WXnRrlF9zzVUcOAnS6SGTJSYX8Nqu2UhbeHpyOEkwvE TmN5V0XvHVBFLcJKKfMIDTpSQKdKLKUmoAdkqGVd5C/dNViilr7dLc33I6IKWLRPGyhv AEsIfDFF7oBpfnmBgMmT2+Eb526wHt/FkGfLEBgklloCw6wmw20mjFlin+ixvjIxruud 7f7tldp3FIIVjpiKdDoPpP0Kdq4qNruup/VNj3L0tMkP9TdfjkmsCtq0vMRUOy7lB4HG II+RQtuQ0cngu91aY8FDmCW/1nSQxuN+7ESjwGvVJlnMno5T2ZJzmgeaZpvlfwaGtbB3 nw0g== X-Forwarded-Encrypted: i=1; AJvYcCV/gjtC2KOUnaVSnS2kg9EUaYmH00M2kSUg1rKehByJwgmq6ThGlYLv8X0tNa9yCE8K+QWJgw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxT8CKzIx55Xgrd0PPeM7iLVJgq7gRWXPubYUsiNK90cpfztDOC CpsKqAvPEgevMki7lbpbcSnVzT8H3Sko98SowGKsV9KT0fHWYhdQtPlJfuT3N+biKFRHZUFQbrG Pz26Doa8OAYDNxlsIPodi2mPboPY= X-Gm-Gg: ASbGncvWxqXC3+/aNb8fO7IpDmaAIr5OgINaGrXdN5oO5skWgni6G9lV7329UkiVnZm 7IpdKi8mKgAOgv2H3OvaRq8RDJR++ImkpdPBjj48rhe8mA3z/hqoeL1233ZCxHsB+Kv5bpKRdDv Xv9IvWIoHqRXohXBKiFk5uZw9o6lZdssry X-Google-Smtp-Source: AGHT+IFNc1GEhSyYA/KqRPFGXGWznyM+tMATL2wzH/obfI8dAAtE162dv5qR2nJfqDR14B2U5G146JxSdTnnK1/Qjmc= X-Received: by 2002:a05:6102:3309:b0:4bb:d062:430 with SMTP id ada2fe7eead31-4c9e4d299c9mr5582523137.0.1744483792314; Sat, 12 Apr 2025 11:49:52 -0700 (PDT) MIME-Version: 1.0 References: <CALG+76edL6PRmODyibLDtAk6_cAy2a4JZ6dV4mRGhRO1h-WwNA@HIDDEN> <86r01yoe8y.fsf@HIDDEN> <CALG+76fvOrn_7cRnj4PJ09-1Jsowq9iS59xeEPS0Yi2BK=ac8A@HIDDEN> <86jz7qo6pk.fsf@HIDDEN> <CALG+76d+JPD_gsOwS3pb6p5r_aCAizsweyemc4no-EKbx-3iFQ@HIDDEN> <86ikn9opda.fsf@HIDDEN> <CALG+76fWNn0ZySae+k7uh+f_eSX7D+MiEVYEqWTXW6YCw39L1g@HIDDEN> <CAN+1HboLzkhcX=16ZUUUj2R5or46AfJjAqoxvQ5Yf9RMXa=7jQ@HIDDEN> <CALG+76eKm0h-2OXvEnVBz8EBA95vf66MWsUgazRwcKZMOfmJ5Q@HIDDEN> In-Reply-To: <CALG+76eKm0h-2OXvEnVBz8EBA95vf66MWsUgazRwcKZMOfmJ5Q@HIDDEN> From: Ship Mints <shipmints@HIDDEN> Date: Sat, 12 Apr 2025 14:49:41 -0400 X-Gm-Features: ATxdqUFC5cqGM7Z4pLSsRCGJQYVGfAZdIzde6PFOeGyNjvM0IzWhTaLS853EGQU Message-ID: <CAN+1Hbp=1Xg87Xa6GjZ4_QL8T3DSHpjYh2qYYNB=m0ZQ0oyf8Q@HIDDEN> Subject: Re: bug#77745: Async native compilation runs every time I start Emacs To: =?UTF-8?Q?Bj=C3=B6rn_Lindqvist?= <bjourne@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000c1e75506329948d1" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77745 Cc: Eli Zaretskii <eliz@HIDDEN>, 77745 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --000000000000c1e75506329948d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Apr 12, 2025 at 2:15=E2=80=AFPM Bj=C3=B6rn Lindqvist <bjourne@gmail= .com> wrote: > > setq is incorrect for overriding native-comp-eln-load-path. Call > startup-redirect-eln-cache only in your early-init.el file. > > > > As far as overriding user-emacs-directory is concerned, for best result= s > you should use the --init-directory command-line argument if you can't li= ve > with the default. The default does respect XDG_CONFIG_HOME and defaults = to > XDG_CONFIG_HOME/emacs or ~/.config/emacs then the more traditional > locations, in that priority. This assumes you do not specify --user. If > you don't use this method, you'll have to do a census of the variables > dependent on user-emacs-directory and fix them all. There currently is n= o > function that does that, and even if there were, if you ran it too late i= n > your startup cycle, external packages would be tainted with the old value= . > > The manual says that you can modify native-comp-eln-load-path directly: > > Sometimes there could be a need to prevent the native compilation > from writing its results, the *.eln files, into a subdirectory of > user-emacs-directory (see The Init File). You can do that by > either changing the value of native-comp-eln-load-path (see > Native-Compilation Variables) or by temporarily pointing the HOME > environment variable to a non-existing directory. > > Regardless, it doesn't matter. Having > > (startup-redirect-eln-cache (expand-file-name "~/.cache/emacs/eln/")) > > in early-init.el is exactly equivalent to having > > (setq native-comp-eln-load-path > (list (expand-file-name "~/tmp/") > "/opt/emacs/lib/emacs/31.0.50/native-lisp/")) > Of course. But you run the risk of incompatibilities later on. in init.el. The native compiler correctly reads and writes most files > in ~/.cache/emacs/eln/ *except* for warnings-28e75f4d-f0ade81c.eln, > icons-eafe82eb-47a1ab50.eln, and cl-lib-8b938900-6d6e9142.eln which it > keeps recompiling every time I start emacs. The only way I've found to > get it to not recompile warnings, icons, and cl-lib is to keep the > default ~/.config/emacs/eln-cache path. > I apologize that I missed what you're trying to accomplish. If you want to avoid compiler warnings, perhaps suppress warnings in early init, and then reenable them in init where it makes sense if you want warnings for external packages but not core packages? The load logic is, I think, find the elc file (or make it, if byte compilation isn't inhibited) along load-path, and if found, probe the eln cache and swap the eln, if found. As far as icons and cl-lib recompiles, not sure here. I also redirect my eln cache into user-emacs-directory/var/eln-cache and I start Emacs sessions gobs of times per day both 30 and 31/master and I don't see this behavior. What platform are you on and does your build have icons and cl-lib in its pre-compiled directory? Are you building Emacs without aot? --000000000000c1e75506329948d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:monospace"><span style=3D"font-family:Arial,Helvetica,sans-serif">= On Sat, Apr 12, 2025 at 2:15=E2=80=AFPM Bj=C3=B6rn Lindqvist <<a href=3D= "mailto:bjourne@HIDDEN">bjourne@HIDDEN</a>> wrote:</span></div></d= iv><div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D"gm= ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,= 204,204);padding-left:1ex">> setq is incorrect for overriding native-com= p-eln-load-path.=C2=A0 Call startup-redirect-eln-cache only in your early-i= nit.el file.<br> ><br> > As far as overriding user-emacs-directory is concerned, for best resul= ts you should use the --init-directory command-line argument if you can'= ;t live with the default.=C2=A0 The default does respect XDG_CONFIG_HOME an= d defaults to XDG_CONFIG_HOME/emacs or ~/.config/emacs then the more tradit= ional locations, in that priority.=C2=A0 This assumes you do not specify --= user.=C2=A0 If you don't use this method, you'll have to do a censu= s of the variables dependent on user-emacs-directory and fix them all.=C2= =A0 There currently is no function that does that, and even if there were, = if you ran it too late in your startup cycle, external packages would be ta= inted with the old value.<br> <br> The manual says that you can modify native-comp-eln-load-path directly:<br> <br> =C2=A0 =C2=A0 Sometimes there could be a need to prevent the native compila= tion<br> =C2=A0 =C2=A0 from writing its results, the *.eln files, into a subdirector= y of<br> =C2=A0 =C2=A0 user-emacs-directory (see The Init File). You can do that by<= br> =C2=A0 =C2=A0 either changing the value of native-comp-eln-load-path (see<b= r> =C2=A0 =C2=A0 Native-Compilation Variables) or by temporarily pointing the = HOME<br> =C2=A0 =C2=A0 environment variable to a non-existing directory.<br> <br> Regardless, it doesn't matter. Having<br> <br> =C2=A0 =C2=A0 (startup-redirect-eln-cache (expand-file-name "~/.cache/= emacs/eln/"))<br> <br> in early-init.el is exactly equivalent to having<br> <br> =C2=A0 =C2=A0 (setq native-comp-eln-load-path<br> =C2=A0 =C2=A0 =C2=A0 (list (expand-file-name "~/tmp/")<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "/opt/emacs/lib/emacs/31.0.5= 0/native-lisp/"))<br></blockquote><div><br></div><div class=3D"gmail_d= efault" style=3D"font-family:monospace">Of course.=C2=A0 But you run the ri= sk of incompatibilities later on.</div><div class=3D"gmail_default" style= =3D"font-family:monospace"><br></div><blockquote class=3D"gmail_quote" styl= e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin= g-left:1ex"> in init.el. The native compiler correctly reads and writes most files<br> in ~/.cache/emacs/eln/ *except* for warnings-28e75f4d-f0ade81c.eln,<br> icons-eafe82eb-47a1ab50.eln, and cl-lib-8b938900-6d6e9142.eln which it<br> keeps recompiling every time I start emacs. The only way I've found to<= br> get it to not recompile warnings, icons, and cl-lib is to keep the<br> default ~/.config/emacs/eln-cache path.<br></blockquote><div><br></div><div= class=3D"gmail_default" style=3D"font-family:monospace">I apologize that I= missed what you're trying to accomplish.=C2=A0 If you want to avoid co= mpiler warnings, perhaps suppress warnings in early init, and then reenable= =C2=A0them in init where it makes sense if you want warnings for external p= ackages but not core packages?</div><div class=3D"gmail_default" style=3D"f= ont-family:monospace"><br></div><div class=3D"gmail_default" style=3D"font-= family:monospace">The load logic is, I think, find=C2=A0the elc file (or ma= ke it, if byte compilation isn't inhibited) along load-path, and if fou= nd, probe the eln cache and swap the eln, if found.</div><div class=3D"gmai= l_default" style=3D"font-family:monospace"><br></div><div class=3D"gmail_de= fault" style=3D"font-family:monospace">As far as icons and cl-lib recompile= s, not sure here.=C2=A0 I also redirect my eln cache into user-emacs-direct= ory/var/eln-cache and I start Emacs sessions gobs of times per day both 30 = and 31/master and I don't see this behavior.=C2=A0 What platform are yo= u on and does your build have icons and cl-lib in its pre-compiled director= y?=C2=A0 Are you building Emacs without aot?</div></div></div> --000000000000c1e75506329948d1--
bug-gnu-emacs@HIDDEN:bug#77745; Package emacs.
Full text available.
Received: (at 77745) by debbugs.gnu.org; 12 Apr 2025 18:15:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 12 14:15:13 2025
Received: from localhost ([127.0.0.1]:58817 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u3fNn-00063k-Q7
for submit <at> debbugs.gnu.org; Sat, 12 Apr 2025 14:15:13 -0400
Received: from mail-ua1-x936.google.com ([2607:f8b0:4864:20::936]:51317)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <bjourne@HIDDEN>) id 1u3fNk-00062s-RK
for 77745 <at> debbugs.gnu.org; Sat, 12 Apr 2025 14:15:09 -0400
Received: by mail-ua1-x936.google.com with SMTP id
a1e0cc1a2514c-86b9ea43955so1149099241.2
for <77745 <at> debbugs.gnu.org>; Sat, 12 Apr 2025 11:15:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1744481703; x=1745086503; darn=debbugs.gnu.org;
h=content-transfer-encoding:cc:to:subject:message-id:date:from
:in-reply-to:references:mime-version:from:to:cc:subject:date
:message-id:reply-to;
bh=l3FmPMLYkExkb20nF0L629caK4TnbbEa+m8ycnu37D8=;
b=AbuEcS6dSD5/1tOozrKd9lLR4d2c7Vif6nMkJJ6v+VSqu15y8pjxkAU7HCK9dEGEpc
dxunPOfX/mAfhLgMdAcuyBBA+I+bxVlXrf3MBsgqFh4k2woXf51lajMvPoKiNrU/W1gs
JasJbVlFrJmqRWfIb2xueFKrx1owTjUfbjR7Hy4PlYX+88fpCB47brdNLBFP0zdL5JAv
At3VLVImkCHHa3/kjtAmArpvxvuUzZWmX5d6cGEBxoHTn5ogt2yDmr1zc3oXpoCkz5lG
Qf3ExI5HtOOmlbNdq1Sgx6LNV178i9Gx3arkBDyRPq7t6MRx5/lgvk8vecShJxFr+2PR
C+hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1744481703; x=1745086503;
h=content-transfer-encoding:cc:to:subject:message-id:date:from
:in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=l3FmPMLYkExkb20nF0L629caK4TnbbEa+m8ycnu37D8=;
b=WuhH1kNsKTHCg3vCMMVOoVml5A5AhI3OF2D2ldpM9t3vTLujr9NvbN4NKvg+EayHwJ
9/eRPHSLE1/f1aMzuApwhfi9IQT47JApQk+kkbZfrTUT7JwKRkL18S+iHM0vmRky/Uvd
M/Abze4fOcyDuSkNQ5gNoLU1Qg/TZt9e7t3DkxJ3Y8DQLE06bkOR5e06szUyuydBwtmB
t2QSMBW+JPmRZJEB4JuvgtRNuGqPDKWGbyvOZWYk94ReetHeR+mKGdTodWhD7ONQc1Th
zOpWEP7DKGv33rVPD07dimXWIVC4xt40o4ydEL9AgB/a9QIilT30sKOpG7pQMtsyYHLK
2DQA==
X-Forwarded-Encrypted: i=1;
AJvYcCWDlzRXz4gRwgDdh9+cMxc7HjT5jGNK1Pt0G5YtCxKAxBs4QhZ7AANSsUjao3kMY4rHZFDiiQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yxq1/l1zCvqpa4hWhI8T4JPBNivsLd6ThabkijSrpYg/eVbJLVQ
M/jDIE6ob/cAeFWL24s0PGyLvUwFyApjuu+IUxbJrXl5M2borRaxvSaHkfalTJVj5vv9x6W2uBT
hlRbKvhwm0S3BLY2CvpateNqmODQ=
X-Gm-Gg: ASbGncsXnOe07jvcoeV2579oGeoGPF281r80tTCcgqjOc22q2cw+p1Xtdo8tOEQR7y4
jX98oUV3EkW2PARelu/lgdQtWI22MkbBMglhOIZFGt9ZXaMKFzdHeoRJ0fR/Icq8cdCXwSA5Nv5
ORq8GZ/24qJER0ys0AMF7P9NkeKIM+jgKZgudBC+C8hsGbd2p7vw==
X-Google-Smtp-Source: AGHT+IG5BAgFy+BHr+fTBDsbTlCmvxx8BExYbJusiIO9qso7w8azVTAfxOQKe1cpkhZmbNX9SN/2pQSaW0CJ9WfYrGI=
X-Received: by 2002:a05:6102:5e91:b0:4c2:d9d3:2aae with SMTP id
ada2fe7eead31-4c9e504ba1fmr5713678137.21.1744481702509; Sat, 12 Apr 2025
11:15:02 -0700 (PDT)
MIME-Version: 1.0
References: <CALG+76edL6PRmODyibLDtAk6_cAy2a4JZ6dV4mRGhRO1h-WwNA@HIDDEN>
<86r01yoe8y.fsf@HIDDEN>
<CALG+76fvOrn_7cRnj4PJ09-1Jsowq9iS59xeEPS0Yi2BK=ac8A@HIDDEN>
<86jz7qo6pk.fsf@HIDDEN>
<CALG+76d+JPD_gsOwS3pb6p5r_aCAizsweyemc4no-EKbx-3iFQ@HIDDEN>
<86ikn9opda.fsf@HIDDEN>
<CALG+76fWNn0ZySae+k7uh+f_eSX7D+MiEVYEqWTXW6YCw39L1g@HIDDEN>
<CAN+1HboLzkhcX=16ZUUUj2R5or46AfJjAqoxvQ5Yf9RMXa=7jQ@HIDDEN>
In-Reply-To: <CAN+1HboLzkhcX=16ZUUUj2R5or46AfJjAqoxvQ5Yf9RMXa=7jQ@HIDDEN>
From: =?UTF-8?Q?Bj=C3=B6rn_Lindqvist?= <bjourne@HIDDEN>
Date: Sat, 12 Apr 2025 20:14:50 +0200
X-Gm-Features: ATxdqUGjKS34N4yH5A_xkG2YW_nRTHGJJQA5UNCabtPDZ-DpCW5TLrV9cd-DdOk
Message-ID: <CALG+76eKm0h-2OXvEnVBz8EBA95vf66MWsUgazRwcKZMOfmJ5Q@HIDDEN>
Subject: Re: bug#77745: Async native compilation runs every time I start Emacs
To: Ship Mints <shipmints@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 77745
Cc: Eli Zaretskii <eliz@HIDDEN>, 77745 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
> setq is incorrect for overriding native-comp-eln-load-path. Call startup=
-redirect-eln-cache only in your early-init.el file.
>
> As far as overriding user-emacs-directory is concerned, for best results =
you should use the --init-directory command-line argument if you can't live=
with the default. The default does respect XDG_CONFIG_HOME and defaults t=
o XDG_CONFIG_HOME/emacs or ~/.config/emacs then the more traditional locati=
ons, in that priority. This assumes you do not specify --user. If you don=
't use this method, you'll have to do a census of the variables dependent o=
n user-emacs-directory and fix them all. There currently is no function th=
at does that, and even if there were, if you ran it too late in your startu=
p cycle, external packages would be tainted with the old value.
The manual says that you can modify native-comp-eln-load-path directly:
Sometimes there could be a need to prevent the native compilation
from writing its results, the *.eln files, into a subdirectory of
user-emacs-directory (see The Init File). You can do that by
either changing the value of native-comp-eln-load-path (see
Native-Compilation Variables) or by temporarily pointing the HOME
environment variable to a non-existing directory.
Regardless, it doesn't matter. Having
(startup-redirect-eln-cache (expand-file-name "~/.cache/emacs/eln/"))
in early-init.el is exactly equivalent to having
(setq native-comp-eln-load-path
(list (expand-file-name "~/tmp/")
"/opt/emacs/lib/emacs/31.0.50/native-lisp/"))
in init.el. The native compiler correctly reads and writes most files
in ~/.cache/emacs/eln/ *except* for warnings-28e75f4d-f0ade81c.eln,
icons-eafe82eb-47a1ab50.eln, and cl-lib-8b938900-6d6e9142.eln which it
keeps recompiling every time I start emacs. The only way I've found to
get it to not recompile warnings, icons, and cl-lib is to keep the
default ~/.config/emacs/eln-cache path.
--=20
mvh/best regards Bj=C3=B6rn Lindqvist
bug-gnu-emacs@HIDDEN:bug#77745; Package emacs.
Full text available.Received: (at 77745) by debbugs.gnu.org; 12 Apr 2025 17:35:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 12 13:35:19 2025 Received: from localhost ([127.0.0.1]:58248 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u3elD-0002IH-8u for submit <at> debbugs.gnu.org; Sat, 12 Apr 2025 13:35:19 -0400 Received: from mail-ua1-x929.google.com ([2607:f8b0:4864:20::929]:43221) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <shipmints@HIDDEN>) id 1u3elA-0002H8-5Y for 77745 <at> debbugs.gnu.org; Sat, 12 Apr 2025 13:35:17 -0400 Received: by mail-ua1-x929.google.com with SMTP id a1e0cc1a2514c-86dc3482b3dso3778348241.0 for <77745 <at> debbugs.gnu.org>; Sat, 12 Apr 2025 10:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744479310; x=1745084110; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QjljjkdPp6SB4hOxmcTQVcGVOwbp22R3XXgJXpFm8jw=; b=DDEQp8dIpIZSegFdP4Kuf3SaW4vm1SX7GzUqv0EH6RdfWK8WQV8ZdZM6IkJO94gSKa 7w35pkW4tRr441ju4LrIuwuD6sv/KNOX5ixDlAM7so+SPCbl6PgMp7ckpEx+oqRrxajq Qf0ff9BI3Trkn6t9NJBPbuwcX2l64zHYj1dhHOa8rApAcDSM7gwbAmpjOwnhqAONG6n8 P+BYyXG/0jnF3ZUW0smR/RTv43aDmqLVUTQ5X90Ob3/uU3CZypQ4gnYZdQwP/xHSBhCV JXuWt9/2jnpdPQXBBo9L5r6DxbBPKZJJ2bf2ZxNc3mI6jqcOliaB6ecoDjWqZwXCZ5RW Hofw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744479310; x=1745084110; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QjljjkdPp6SB4hOxmcTQVcGVOwbp22R3XXgJXpFm8jw=; b=M8L27cynp7KBlKn8Jy6SxPubTBulKESYYybNO2sTf4Q0q0ykA1pOcev50qmEthoA6m 09uRFvYaUKz8aS/mgMYktb2cvSXa7NLyeFijko3x3PePtkqHSwxvhSKJ48BNzKcdCQpQ zqNwcZAbBaa5+ftx1XDHDkD3xQJVPxhmbGV2eaDNcbwI+Qrr1Wayxtk6oMzsi3WE+3v5 BP/IGtJesjDdT201F/KUclVVcXtBP0j9H12jN4H3+skoAQ1Op4U3FxSNgrQ7qS4REPOT KruzENroXKuh0gVDKRx48BdN+K5FMopfnfVT9sjdXRh9W0/PjX+okgGqQnAEKYpn4MZA RJYA== X-Forwarded-Encrypted: i=1; AJvYcCUBNs35d+GILzFsRDUP4PjXXNEacdnlXOfVblLlCxrQjMoZcfFurmKc4hbGRJb72ym68WHDqw==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yz2PdyNoy8JZgpYHgenmSUAx+LKC3zH2iVJJ7gVjgib2a8qbZ7V RIKK6vifYxsRckeKJ1PDOHjB7JsFongC3eIKaArA2qlpWDMFIRVeJ5Rmc81n+Nu+DArIY6Lox02 KdDAYnswNJPloM1nMnKMJWQFsM5HFcz7T X-Gm-Gg: ASbGncvOkpEYYONeT+HYpCzgAMXB3Ygu1uGVeGGKXNWuh5M7eJ/75lWDOf23/E9vssf vZwfcgA6LH2Uqi1+/zjNPeojwuUdVZCvEDLjpuvcoM9tuezslEtTMbwrR4Xqk900RSeQmxY5rIV rFc4qzubTvsNmZQI1oFSAorg== X-Google-Smtp-Source: AGHT+IF4HPFCRQctVzF6n8+AFqqK90g7f36YdVE3meU031Hm/Gb/7b/tZXlnkUhAIoWdMYdwU2aHdo0l4dhH2Xz9pgk= X-Received: by 2002:a05:6122:1e09:b0:524:2fe0:61bc with SMTP id 71dfb90a1353d-527c2fd0e9bmr5497388e0c.5.1744479310213; Sat, 12 Apr 2025 10:35:10 -0700 (PDT) MIME-Version: 1.0 References: <CALG+76edL6PRmODyibLDtAk6_cAy2a4JZ6dV4mRGhRO1h-WwNA@HIDDEN> <86r01yoe8y.fsf@HIDDEN> <CALG+76fvOrn_7cRnj4PJ09-1Jsowq9iS59xeEPS0Yi2BK=ac8A@HIDDEN> <86jz7qo6pk.fsf@HIDDEN> <CALG+76d+JPD_gsOwS3pb6p5r_aCAizsweyemc4no-EKbx-3iFQ@HIDDEN> <86ikn9opda.fsf@HIDDEN> <CALG+76fWNn0ZySae+k7uh+f_eSX7D+MiEVYEqWTXW6YCw39L1g@HIDDEN> In-Reply-To: <CALG+76fWNn0ZySae+k7uh+f_eSX7D+MiEVYEqWTXW6YCw39L1g@HIDDEN> From: Ship Mints <shipmints@HIDDEN> Date: Sat, 12 Apr 2025 13:34:59 -0400 X-Gm-Features: ATxdqUEk4GdLT9TXo2kY4LdeiEoPAf_nPJcN66BM_-kg1J0CzGY5aZertp5uRpI Message-ID: <CAN+1HboLzkhcX=16ZUUUj2R5or46AfJjAqoxvQ5Yf9RMXa=7jQ@HIDDEN> Subject: Re: bug#77745: Async native compilation runs every time I start Emacs To: =?UTF-8?Q?Bj=C3=B6rn_Lindqvist?= <bjourne@HIDDEN> Content-Type: multipart/alternative; boundary="0000000000009a7b500632983daf" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77745 Cc: Eli Zaretskii <eliz@HIDDEN>, 77745 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --0000000000009a7b500632983daf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Apr 12, 2025 at 1:09=E2=80=AFPM Bj=C3=B6rn Lindqvist <bjourne@gmail= .com> wrote: > Hello again, > > I tried setting native-comp-eln-load-path explicitly in init.el > > (setq native-comp-eln-load-path > (list (expand-file-name "~/tmp/") > "/opt/emacs/lib/emacs/31.0.50/native-lisp/")) > > and this works much better. The native compiler only > writes to ~/tmp/31.0.50-859de2ee/. Not in any directory under > ~/.config/emacs. Only the files warnings-28e75f4d-f0ade81c.eln, > icons-eafe82eb-47a1ab50.eln, and cl-lib-8b938900-6d6e9142.eln gets > recompiled on startup. > > > What this means is that if your init files load packages, directly or > > indirectly, before they modify user-emacs-directory, the native > > compilation will start for those packages using the value of > > native-comp-eln-load-path that is not what your session will > > subsequently use. And packages compiled after user-emacs-directory is > > modified will have their *.eln files deposited in another directory. > > > IOW, the order in which you modify user-emacs-directory and load > > packages that need native compilation matters _a_lot_, as you have > > discovered. > > The first sexp of my init.el is > > (setq user-emacs-directory "~/.config/emacs/lisp/") > > which is (?) executed *before* the native compiler kicks in. Unless > something odd happens during *parsing* of init.el, but that seems > far-fetched. > > What I think happens is that the native compiler builds the > native-comp-eln-load-path based on the value of user-emacs-directory > before init.el is loaded. Then user-emacs-directory gets modified and > this changes the path it *writes* to, but does nothing to the paths it > *reads* from. So it compiles the files and writes them to a directory > it won't read from the next time I start Emacs. Indeed, if I log > native-comp-eln-load-path I can see that the value is: > > (~/.config/emacs/eln-cache/ /opt/emacs/lib/emacs/31.0.50/native-lisp/= ) > > but the native compiler writes to ~/.config/emacs/lisp/eln-cache/ > (note: /lisp/), contradicting the manual: "By default, > asynchronous native compilation writes the *.eln files it produces to > a subdirectory of the first writable directory specified by the > native-comp-eln-load-path variable". > > So it must be a bug that setting user-emacs-directory updates the path > the native compiler writes to, but not the path(s) it reads from. > > > We recommend not to modify the value of user-emacs-directory, > > because doing that might break various initializations Emacs > > performs during startup. > > Are there technical reasons user-emacs-directory can't be changed? > Isn't code that relies on user-emacs-directory having a specific value > or to never change is buggy? > > > The eln cache Emacs uses is not really a "cache" XDG spec had in mind. > > The *.eln files are not "non-essential", since we want them to > > persist, and removing that directory will make the next startup of > > Emacs significantly longer and more expensive. > > I think what you're describing is exactly what a cache does and > exactly how other programs use $XDG_CACHE_HOME. Of course a program > would take longer to start after you blow up its cache. > setq is incorrect for overriding native-comp-eln-load-path. Call startup-redirect-eln-cache only in your early-init.el file. As far as overriding user-emacs-directory is concerned, for best results you should use the --init-directory command-line argument if you can't live with the default. The default does respect XDG_CONFIG_HOME and defaults to XDG_CONFIG_HOME/emacs or ~/.config/emacs then the more traditional locations, in that priority. This assumes you do not specify --user. If you don't use this method, you'll have to do a census of the variables dependent on user-emacs-directory and fix them all. There currently is no function that does that, and even if there were, if you ran it too late in your startup cycle, external packages would be tainted with the old value. --0000000000009a7b500632983daf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:monospace"><span style=3D"font-family:Arial,Helvetica,sans-serif">= On Sat, Apr 12, 2025 at 1:09=E2=80=AFPM Bj=C3=B6rn Lindqvist <<a href=3D= "mailto:bjourne@HIDDEN">bjourne@HIDDEN</a>> wrote:</span></div></d= iv><div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D"gm= ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,= 204,204);padding-left:1ex">Hello again,<br> <br> I tried setting native-comp-eln-load-path explicitly in init.el<br> <br> =C2=A0 =C2=A0 (setq native-comp-eln-load-path<br> =C2=A0 =C2=A0 =C2=A0 (list (expand-file-name "~/tmp/")<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "/opt/emacs/lib/emacs/31.0.5= 0/native-lisp/"))<br> <br> and this works much better. The native compiler only<br> writes to ~/tmp/31.0.50-859de2ee/. Not in any directory under<br> ~/.config/emacs. Only the files warnings-28e75f4d-f0ade81c.eln,<br> icons-eafe82eb-47a1ab50.eln, and cl-lib-8b938900-6d6e9142.eln gets<br> recompiled on startup.<br> <br> > What this means is that if your init files load packages, directly or<= br> > indirectly, before they modify user-emacs-directory, the native<br> > compilation will start for those packages using the value of<br> > native-comp-eln-load-path that is not what your session will<br> > subsequently use.=C2=A0 And packages compiled after user-emacs-directo= ry is<br> > modified will have their *.eln files deposited in another directory.<b= r> <br> > IOW, the order in which you modify user-emacs-directory and load<br> > packages that need native compilation matters _a_lot_, as you have<br> > discovered.<br> <br> The first sexp of my init.el is<br> <br> =C2=A0 =C2=A0 (setq user-emacs-directory "~/.config/emacs/lisp/")= <br> <br> which is (?) executed *before* the native compiler kicks in. Unless<br> something odd happens during *parsing* of init.el, but that seems<br> far-fetched.<br> <br> What I think happens is that the native compiler builds the<br> native-comp-eln-load-path based on the value of user-emacs-directory<br> before init.el is loaded. Then user-emacs-directory gets modified and<br> this changes the path it *writes* to, but does nothing to the paths it<br> *reads* from. So it compiles the files and writes them to a directory<br> it won't read from the next time I start Emacs. Indeed, if I log<br> native-comp-eln-load-path I can see that the value is:<br> <br> =C2=A0 =C2=A0 (~/.config/emacs/eln-cache/ /opt/emacs/lib/emacs/31.0.50/nati= ve-lisp/)<br> <br> but the native compiler writes to ~/.config/emacs/lisp/eln-cache/<br> (note: /lisp/), contradicting the manual: "By default,<br> asynchronous native compilation writes the *.eln files it produces to<br> a subdirectory of the first writable directory specified by the<br> native-comp-eln-load-path variable".<br> <br> So it must be a bug that setting user-emacs-directory updates the path<br> the native compiler writes to, but not the path(s) it reads from.<br> <br> > We recommend not to modify the value of user-emacs-directory,<br> > because doing that might break various initializations Emacs<br> > performs during startup.<br> <br> Are there technical reasons user-emacs-directory can't be changed?<br> Isn't code that relies on user-emacs-directory having a specific value<= br> or to never change is buggy?<br> <br> > The eln cache Emacs uses is not really a "cache" XDG spec ha= d in mind.<br> > The *.eln files are not "non-essential", since we want them = to<br> > persist, and removing that directory will make the next startup of<br> > Emacs significantly longer and more expensive.<br> <br> I think what you're describing is exactly what a cache does and<br> exactly how other programs use $XDG_CACHE_HOME. Of course a program<br> would take longer to start after you blow up its cache.<br></blockquote><di= v><br></div><div class=3D"gmail_default" style=3D"font-family:monospace">se= tq is incorrect for overriding native-comp-eln-load-path.=C2=A0 Call startu= p-redirect-eln-cache only in your early-init.el file.</div><div class=3D"gm= ail_default" style=3D"font-family:monospace"><br></div><div class=3D"gmail_= default" style=3D"font-family:monospace">As far as overriding user-emacs-di= rectory is concerned, for best results you should use the --init-directory = command-line argument if you can't live with the default.=C2=A0 The def= ault does respect XDG_CONFIG_HOME and defaults to XDG_CONFIG_HOME/emacs or = ~/.config/emacs then the more traditional locations, in that priority.=C2= =A0 This assumes you do not specify --user.=C2=A0 If you don't use this= method, you'll have to do a census of the variables dependent on user-= emacs-directory and fix them all.=C2=A0 There currently is no function that= does that, and even if there were, if you ran it too late in your startup = cycle, external packages would be tainted with the old value.</div></div></= div> --0000000000009a7b500632983daf--
bug-gnu-emacs@HIDDEN:bug#77745; Package emacs.
Full text available.
Received: (at 77745) by debbugs.gnu.org; 12 Apr 2025 17:08:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 12 13:08:30 2025
Received: from localhost ([127.0.0.1]:58010 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u3eLD-0006jY-R6
for submit <at> debbugs.gnu.org; Sat, 12 Apr 2025 13:08:30 -0400
Received: from mail-vk1-xa2d.google.com ([2607:f8b0:4864:20::a2d]:43088)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <bjourne@HIDDEN>) id 1u3eL9-0006hl-5X
for 77745 <at> debbugs.gnu.org; Sat, 12 Apr 2025 13:08:25 -0400
Received: by mail-vk1-xa2d.google.com with SMTP id
71dfb90a1353d-523f721bc63so3616697e0c.0
for <77745 <at> debbugs.gnu.org>; Sat, 12 Apr 2025 10:08:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1744477697; x=1745082497; darn=debbugs.gnu.org;
h=content-transfer-encoding:cc:to:subject:message-id:date:from
:in-reply-to:references:mime-version:from:to:cc:subject:date
:message-id:reply-to;
bh=921K6Nf2I6Hg9SsixIzP2lqQMxdgLfgKRWxgX6yIQY4=;
b=CQzGndDdZ5MF0fhVYcuto3BIRDHB2zkt8sxDdgcfh9VvdLtXxM5kHcD37I7ul0zByY
B2Fi+6aLrTl4AEqKp4erCpTC9xbAglk0plHtCrm/Cakltk0E+IPDgwzARfpBZsQfEpTe
6GHZF18CCniEwbQMVUn4RVnvAN3qnIxlXDRRMkC0YelXdAZl4Y+H2Rm3iW7h5QBst54g
G4ECxUfBlExP7QVfevM8xUVyTjWkOFtyfXTEd6LfrqBKIRgI/s5zwRN8D7T+/JfcSRrd
UdvGe+lvcKqPHD3Cviogk0ynDeDIGLYC2FV2G1ePrmNFvecBXGB/rhdgC8T0t/0nd/TE
qv0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1744477697; x=1745082497;
h=content-transfer-encoding:cc:to:subject:message-id:date:from
:in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=921K6Nf2I6Hg9SsixIzP2lqQMxdgLfgKRWxgX6yIQY4=;
b=kURAWWbNsNM0ApoRKoOiruVSwSF/TL22FgiMvzAZNbbNFZz0V3QbE9aKWwsvxTRYnC
bHOuxOGVQrEuAemPy+bB0j4w2P3JENAkHVaKdrDvrY37LJgTCYxMCXEbDYh4FNY5k31y
O6oBakSit5qlTfYzlJoH8zuNmpg/h3Xb8lMS8Z+sA6Y6W+JFf+JJY/b+/NzWmFXkVFTx
x1g3FZSQ/iiWMULffMYkRtJpH7k88VDw+KMtSF3eNRxKwy9AEh1Hp9s1IOHvH0atbpEx
lSM4Cs266vbpGTT/xYqORy+y2MSR6nqBJ1dNtfGBHrZCoEwG9WCDEYgBFckGZQ2MEiuQ
6gAw==
X-Gm-Message-State: AOJu0Yw1XNUU0isCsDc9ngAz2HbEc9H/I+aKFHAnMdyc+AY9mL9F3JlP
jRjHKubKwhLAHqi2SGT3NdW6wwLwfTEEQPhDBrJ3ckR5Osy/g90deD9mm1KMNq6q+ft4rDSbK/Z
hf3t6FQO8HA+/NrGD47q4Nnr8uKA=
X-Gm-Gg: ASbGncspElK452NLNbW6uLIVVyno2NlREorUpoUtS8LrcQH1YAofgPCYTJyCnwkkbdB
iyPZSDaLSjxwFPxttiJE0pqtfweFUEIstnrGuodkO93ipm7up0+klg90yZAf3IBeyQwIrZ+Irkt
Ycj9NVthM352wvdla5OKT/eVI2uPmCh4F+U23qpjcwVIC4MQU4iQ==
X-Google-Smtp-Source: AGHT+IGTnNE4SQYu9S8Zp9u0sdOS63RsyZMsqkyl1V73O5y+s7SoprMx73H03GPs8x2qojLpbfsk8Yvq/UcApIJ8cv0=
X-Received: by 2002:a05:6122:490c:b0:523:dbd5:4e7f with SMTP id
71dfb90a1353d-527b5e9ff0cmr9925756e0c.3.1744477697259; Sat, 12 Apr 2025
10:08:17 -0700 (PDT)
MIME-Version: 1.0
References: <CALG+76edL6PRmODyibLDtAk6_cAy2a4JZ6dV4mRGhRO1h-WwNA@HIDDEN>
<86r01yoe8y.fsf@HIDDEN>
<CALG+76fvOrn_7cRnj4PJ09-1Jsowq9iS59xeEPS0Yi2BK=ac8A@HIDDEN>
<86jz7qo6pk.fsf@HIDDEN>
<CALG+76d+JPD_gsOwS3pb6p5r_aCAizsweyemc4no-EKbx-3iFQ@HIDDEN>
<86ikn9opda.fsf@HIDDEN>
In-Reply-To: <86ikn9opda.fsf@HIDDEN>
From: =?UTF-8?Q?Bj=C3=B6rn_Lindqvist?= <bjourne@HIDDEN>
Date: Sat, 12 Apr 2025 19:08:05 +0200
X-Gm-Features: ATxdqUFNly722JRG2m3EV5BqsT5EbpJPzKIgEVt3uA2AthCvLBGU9bZeQ79KQOk
Message-ID: <CALG+76fWNn0ZySae+k7uh+f_eSX7D+MiEVYEqWTXW6YCw39L1g@HIDDEN>
Subject: Re: bug#77745: Async native compilation runs every time I start Emacs
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 77745
Cc: 77745 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Hello again,
I tried setting native-comp-eln-load-path explicitly in init.el
(setq native-comp-eln-load-path
(list (expand-file-name "~/tmp/")
"/opt/emacs/lib/emacs/31.0.50/native-lisp/"))
and this works much better. The native compiler only
writes to ~/tmp/31.0.50-859de2ee/. Not in any directory under
~/.config/emacs. Only the files warnings-28e75f4d-f0ade81c.eln,
icons-eafe82eb-47a1ab50.eln, and cl-lib-8b938900-6d6e9142.eln gets
recompiled on startup.
> What this means is that if your init files load packages, directly or
> indirectly, before they modify user-emacs-directory, the native
> compilation will start for those packages using the value of
> native-comp-eln-load-path that is not what your session will
> subsequently use. And packages compiled after user-emacs-directory is
> modified will have their *.eln files deposited in another directory.
> IOW, the order in which you modify user-emacs-directory and load
> packages that need native compilation matters _a_lot_, as you have
> discovered.
The first sexp of my init.el is
(setq user-emacs-directory "~/.config/emacs/lisp/")
which is (?) executed *before* the native compiler kicks in. Unless
something odd happens during *parsing* of init.el, but that seems
far-fetched.
What I think happens is that the native compiler builds the
native-comp-eln-load-path based on the value of user-emacs-directory
before init.el is loaded. Then user-emacs-directory gets modified and
this changes the path it *writes* to, but does nothing to the paths it
*reads* from. So it compiles the files and writes them to a directory
it won't read from the next time I start Emacs. Indeed, if I log
native-comp-eln-load-path I can see that the value is:
(~/.config/emacs/eln-cache/ /opt/emacs/lib/emacs/31.0.50/native-lisp/)
but the native compiler writes to ~/.config/emacs/lisp/eln-cache/
(note: /lisp/), contradicting the manual: "By default,
asynchronous native compilation writes the *.eln files it produces to
a subdirectory of the first writable directory specified by the
native-comp-eln-load-path variable".
So it must be a bug that setting user-emacs-directory updates the path
the native compiler writes to, but not the path(s) it reads from.
> We recommend not to modify the value of user-emacs-directory,
> because doing that might break various initializations Emacs
> performs during startup.
Are there technical reasons user-emacs-directory can't be changed?
Isn't code that relies on user-emacs-directory having a specific value
or to never change is buggy?
> The eln cache Emacs uses is not really a "cache" XDG spec had in mind.
> The *.eln files are not "non-essential", since we want them to
> persist, and removing that directory will make the next startup of
> Emacs significantly longer and more expensive.
I think what you're describing is exactly what a cache does and
exactly how other programs use $XDG_CACHE_HOME. Of course a program
would take longer to start after you blow up its cache.
--
mvh/best regards Bj=C3=B6rn Lindqvist
bug-gnu-emacs@HIDDEN:bug#77745; Package emacs.
Full text available.
Received: (at 77745) by debbugs.gnu.org; 12 Apr 2025 06:39:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 12 02:39:25 2025
Received: from localhost ([127.0.0.1]:53458 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u3UWT-0003RZ-B1
for submit <at> debbugs.gnu.org; Sat, 12 Apr 2025 02:39:25 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:59838)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1u3UWR-0003RH-2v
for 77745 <at> debbugs.gnu.org; Sat, 12 Apr 2025 02:39:23 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1u3UWK-0005rW-BD; Sat, 12 Apr 2025 02:39:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
Date; bh=6+Me3s0kHwPlVcfs8R98M21DQXxmD95LZFd3/u7zHco=; b=hAiLNamZnSxcoEs10P4g
LZdmZXnOL7t7m/TCsww15Ho7gXSMN8Qf7gqJ2EWf7/kG+2Zytqmm4pwRcBRwnSl8JJWdmrKKl6cFq
htRKc84AlGHIaB6e/ZDLZlZ16cCd57Jqgl8P0cpFRv5jCSTlnsdAe7WwxIU9uW1B4olDP7RA8BH2W
bMWILP2Qh9YaY+OMMdyu2UZNJkYa4AomHqGZgomhTnbA/jtuyQ9nIz6llynHOQWQKbxkZvO5wzrJy
tMz2Qbnyh/ia+sgwmE16MwrLJPNw6HibIqbPEwmId6B9sltWoYVcQqfpTydG8EjzTuKttP4hyXcNK
Y5SoZW/B68ajNA==;
Date: Sat, 12 Apr 2025 09:39:13 +0300
Message-Id: <86ikn9opda.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: =?utf-8?Q?Bj=C3=B6rn?= Lindqvist <bjourne@HIDDEN>
In-Reply-To: <CALG+76d+JPD_gsOwS3pb6p5r_aCAizsweyemc4no-EKbx-3iFQ@HIDDEN>
(message from =?utf-8?Q?Bj=C3=B6rn?= Lindqvist on Fri, 11 Apr 2025 23:08:16
+0200)
Subject: Re: bug#77745: Async native compilation runs every time I start Emacs
References: <CALG+76edL6PRmODyibLDtAk6_cAy2a4JZ6dV4mRGhRO1h-WwNA@HIDDEN>
<86r01yoe8y.fsf@HIDDEN>
<CALG+76fvOrn_7cRnj4PJ09-1Jsowq9iS59xeEPS0Yi2BK=ac8A@HIDDEN>
<86jz7qo6pk.fsf@HIDDEN>
<CALG+76d+JPD_gsOwS3pb6p5r_aCAizsweyemc4no-EKbx-3iFQ@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 77745
Cc: 77745 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> From: Björn Lindqvist <bjourne@HIDDEN>
> Date: Fri, 11 Apr 2025 23:08:16 +0200
> Cc: 77745 <at> debbugs.gnu.org
>
> > Why are you setting the value of user-emacs-directory?
>
> Because I want the directory emacs packages throw random stuff in to
> be distinct from my actual configuration directory. Ephemeral stuff
> like ido.last does not belong in the same directory as init.el.
>
> > Then please refrain from changing the value of user-emacs-directory.
>
> I won't. But it is not really clear from the documentation that
> user-emacs-directory is not user modifiable. If you google it you can
> find plenty of examples of people overriding it in init.el to, for
> example, install competing emacs environments (DoomEmacs +
> SpacEmacs):
>
> https://emacs.stackexchange.com/questions/4253/how-to-start-emacs-with-a-custom-user-emacs-directory
>
> I assume the same holds true for native-comp-eln-load-path and you are
> not supposed to touch that variable either?
People who modify user-emacs-directory in their init files should read
the manual very carefully, and should really understand what they are
doing. Here are some facts that you probably knew, but perhaps never
considered together to realize what would be the effect of what you
are doing:
. user-emacs-directory is determined by the startup code, as a side
effect of looking for your init files
. the startup code then loads the init files and executes their code
. native-comp-eln-load-path is computed by the startup code, and it
has the value of user-emacs-directory pushed onto the list
What this means is that if your init files load packages, directly or
indirectly, before they modify user-emacs-directory, the native
compilation will start for those packages using the value of
native-comp-eln-load-path that is not what your session will
subsequently use. And packages compiled after user-emacs-directory is
modified will have their *.eln files deposited in another directory.
IOW, the order in which you modify user-emacs-directory and load
packages that need native compilation matters _a_lot_, as you have
discovered.
So, if you really _must_ modify user-emacs-directory, you should do it
in early-init file, and do it the very first thing there. (Of course,
this means that all the other init files should then live in the
directory which is the updated value of user-emacs-directory.) We
recommend not to modify the value of user-emacs-directory, because
doing that might break various initializations Emacs performs during
startup.
> > Sorry, I don't understand the question. What is "the configuration
> > hierarchy"?
>
> It's from the XDG Base Directory specification. It stipulates that to
> make it easier for users and programs to find files the configuration
> files of a program should be stored in ~/.config/<progname> and
> "user-specific non-essential (cached) data" should be stored in
> ~/.cache/<progname>. The advantage of this scheme is that if you want
> to reclaim disk space you can simply rm -rf ~/.cache/<progname> and if
> you want to reset a program to its factory default rm -rf
> ~/.config/<progname>.
The eln cache Emacs uses is not really a "cache" XDG spec had in mind.
The *.eln files are not "non-essential", since we want them to
persist, and removing that directory will make the next startup of
Emacs significantly longer and more expensive. Therefore, we decided
to have the cache under user-emacs-directory, as Emacs generally does
for all of its files.
bug-gnu-emacs@HIDDEN:bug#77745; Package emacs.
Full text available.Received: (at 77745) by debbugs.gnu.org; 11 Apr 2025 21:10:04 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 11 17:10:03 2025 Received: from localhost ([127.0.0.1]:51968 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u3LdT-0001Eo-04 for submit <at> debbugs.gnu.org; Fri, 11 Apr 2025 17:10:03 -0400 Received: from mail-ua1-x92c.google.com ([2607:f8b0:4864:20::92c]:55521) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <bjourne@HIDDEN>) id 1u3LdQ-0001EC-AG for 77745 <at> debbugs.gnu.org; Fri, 11 Apr 2025 17:10:01 -0400 Received: by mail-ua1-x92c.google.com with SMTP id a1e0cc1a2514c-86d5a786c7cso1074953241.2 for <77745 <at> debbugs.gnu.org>; Fri, 11 Apr 2025 14:10:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744405794; x=1745010594; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=yVbQmr3nGMhjzzzriAz4ZBXKsBYMflG6TH5ayiyJ7iE=; b=YAlF62j7en9coUi1wxPViD3qHEkClvAo9rRVlgimdOzv0QfR5Tr2UT4SAKJyO9QkTj 5FpQuWNvbDcWRcIwRy9xzxyqx/uUkdQbHNziAhIupNlEDkjKs5OW1pFPgberVMH93gLv OLYW0m61gdABAGJcv6AnqmpcrYRWmOCh2M9NancnJqFrKWJ5drHNqYH/UfdDoYsK0R6E 4miwj/Jw1jMjvuJy5BXJ3H2mCl/dRTKSn+3Lp8+HgoZbYDgvuW8BqgExGKh9nOX1ZmVS WjfuhyiAbD8RqFsWI/e143aixDUMRwz3DJ1f4WoUDxx43/TwTUAveP3rX/Zv7owRAJFt jf/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744405794; x=1745010594; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=yVbQmr3nGMhjzzzriAz4ZBXKsBYMflG6TH5ayiyJ7iE=; b=gL8VH36BX1KlzX30Pej+47krHAhQRQkdwEM53PgQa6N4+V0mgddgk4NI4GlzsVwZj3 XIytCNuTX95Ue4Jp68yolR4h4oKGvDDzbv8EgSFojW+VT//LjgIoAEyZX+5y6GA6Zzue ADuYG1hjozkTMfAFZTbflgzHFYGuamvBS3j1HLIpQRremQHBmhGvEgyWN2uBZYiFba1D NuiLd5UUhVz3mNxoJt0qyZ36niQEQ1L1e0EAdUFa7V4Bby2V2gxL0h22RPGISz3BEg4c 6DKzgl79l8aUQguLS6RL2VSC8bJPWHg/Xp78AY37NITvq9BIYy5Kt8WxqJvLbdPNnjwc rzGA== X-Gm-Message-State: AOJu0YxA41H4ESulkRmWT7AvI4KMrvSuJX9OZjN66bxIZZCqSH1RoEfa sFpqB3Jf/TNdcJ4TJRXqGdsPmRV5MBrqGkmGb+YXfFleaQl7fmsbnd2Cun58cJ4eveg1/GCjK/1 X0739ggovbceYqRyi4o2k8aBoyXo= X-Gm-Gg: ASbGncv0DaXTS7GUc4hmhXxbeimjbYukRYYZKVgABQ1YLaz09c3y1ca8V+TZaevSDok nEokEZW24NrOOsPUY9N9bpx6P63ZtUu1NcuIxeHc2pXU6+txhNK8f3W2tZGJVQ4jG187tOSM6We QM5e+7JynEptAyvEAXJTjnKLs= X-Google-Smtp-Source: AGHT+IHPw3UuZ/MOCUgpWrUKZ0ULl1tHqPTPzbi+1qAB3pOC5Hsuk3MyL1n9mJIPqPAENhzcEkfBkMieEUYW309I2+Y= X-Received: by 2002:a05:6102:568c:b0:4b6:20a5:8a11 with SMTP id ada2fe7eead31-4c9e4ebb1c8mr3777456137.1.1744405793743; Fri, 11 Apr 2025 14:09:53 -0700 (PDT) MIME-Version: 1.0 References: <CALG+76edL6PRmODyibLDtAk6_cAy2a4JZ6dV4mRGhRO1h-WwNA@HIDDEN> <86r01yoe8y.fsf@HIDDEN> <CALG+76fvOrn_7cRnj4PJ09-1Jsowq9iS59xeEPS0Yi2BK=ac8A@HIDDEN> <86jz7qo6pk.fsf@HIDDEN> In-Reply-To: <86jz7qo6pk.fsf@HIDDEN> From: =?UTF-8?Q?Bj=C3=B6rn_Lindqvist?= <bjourne@HIDDEN> Date: Fri, 11 Apr 2025 23:08:16 +0200 X-Gm-Features: ATxdqUGY6moaurUnentTi-IfIpC-9xQsutisihC-vWmqHeEdq5w2zrpSkS-282Y Message-ID: <CALG+76d+JPD_gsOwS3pb6p5r_aCAizsweyemc4no-EKbx-3iFQ@HIDDEN> Subject: Re: bug#77745: Async native compilation runs every time I start Emacs To: Eli Zaretskii <eliz@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77745 Cc: 77745 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > Why are you setting the value of user-emacs-directory? Because I want the directory emacs packages throw random stuff in to be distinct from my actual configuration directory. Ephemeral stuff like ido.last does not belong in the same directory as init.el. > Then please refrain from changing the value of user-emacs-directory. I won't. But it is not really clear from the documentation that user-emacs-directory is not user modifiable. If you google it you can find plenty of examples of people overriding it in init.el to, for example, install competing emacs environments (DoomEmacs + SpacEmacs): https://emacs.stackexchange.com/questions/4253/how-to-start-emacs-with-a-cu= stom-user-emacs-directory I assume the same holds true for native-comp-eln-load-path and you are not supposed to touch that variable either? > Sorry, I don't understand the question. What is "the configuration > hierarchy"? It's from the XDG Base Directory specification. It stipulates that to make it easier for users and programs to find files the configuration files of a program should be stored in ~/.config/<progname> and "user-specific non-essential (cached) data" should be stored in ~/.cache/<progname>. The advantage of this scheme is that if you want to reclaim disk space you can simply rm -rf ~/.cache/<progname> and if you want to reset a program to its factory default rm -rf ~/.config/<progname>. --=20 mvh/best regards Bj=C3=B6rn Lindqvist
bug-gnu-emacs@HIDDEN:bug#77745; Package emacs.
Full text available.Received: (at 77745) by debbugs.gnu.org; 11 Apr 2025 19:10:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 11 15:10:13 2025 Received: from localhost ([127.0.0.1]:51777 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u3JlV-0003jo-5S for submit <at> debbugs.gnu.org; Fri, 11 Apr 2025 15:10:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46636) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1u3JlQ-0003hW-PM for 77745 <at> debbugs.gnu.org; Fri, 11 Apr 2025 15:10:11 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1u3JlL-0005Rt-Bz; Fri, 11 Apr 2025 15:10:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=/QN0E3CY+kVV9wji7oVF1eapiSVHDgMNkZ7/PVCMwK0=; b=VQZWK1NTKHSo2b0AbW8v ARV2DhcVguGSEL9HcA3pgkaeRVRQphEFfFdxFQ3kWQAGRZir2CjypHg1raqMSM8cE1mA+TPvx0Syg o447bzxkf3DwLgwivWRGApNeXUsMw1zES9vvQKAS7I+9X0adagutrHGUWPI8m3CP8AXGelsOIEqLx H/WgzTh39MGe4biKuxrb6XiJ5fcZruS1aRypXLI4tMh/JleOM4K0vNA7q76HK2qJXcC3I0934IRwM 0dP2FUQnsLWT51AZQHeiC2bbHYY2mSAEJKGlvpiizGd6UTaQCcMsl2YprOHAKPOx7/QhQ/T6eyGXy 5ANh8yq7wAaEjw==; Date: Fri, 11 Apr 2025 22:09:59 +0300 Message-Id: <86jz7qo6pk.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?utf-8?Q?Bj=C3=B6rn?= Lindqvist <bjourne@HIDDEN> In-Reply-To: <CALG+76fvOrn_7cRnj4PJ09-1Jsowq9iS59xeEPS0Yi2BK=ac8A@HIDDEN> (message from =?utf-8?Q?Bj=C3=B6rn?= Lindqvist on Fri, 11 Apr 2025 20:50:17 +0200) Subject: Re: bug#77745: Async native compilation runs every time I start Emacs References: <CALG+76edL6PRmODyibLDtAk6_cAy2a4JZ6dV4mRGhRO1h-WwNA@HIDDEN> <86r01yoe8y.fsf@HIDDEN> <CALG+76fvOrn_7cRnj4PJ09-1Jsowq9iS59xeEPS0Yi2BK=ac8A@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77745 Cc: 77745 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Björn Lindqvist <bjourne@HIDDEN> > Date: Fri, 11 Apr 2025 20:50:17 +0200 > Cc: 77745 <at> debbugs.gnu.org > > > Do you see the *.eln files created each time the native compilation is > > triggered? If so, are these files recreated using the same hashes in > > the file name, or do the hashes change? Are the sources moved between > > the sessions, perhaps? Are you always starting the same Emacs binary, > > or do you rebuild Emacs between sessions? Did you customize the value > > of native-comp-eln-load-path from its default? > > Yes. Same hashes. No. Same binary. Yes! At the top of my init.el I have > > (setq user-emacs-directory "~/.config/emacs/lisp/") > > causing *most* .eln files to be dumped in > ~/.config/emacs/lisp/eln-cache/31.0.50-859de2ee. Why are you setting the value of user-emacs-directory? > However, two > mysterious files are still being written to > ~/.config/emacs/eln-cache/31.0.50-859de2ee (no lisp) in the path: > > subr--trampoline-6d616b652d70726f63657373_make_process_0.eln > subr--trampoline-616c6c2d636f6d706c6574696f6e73_all_completions_0.eln Probably because that happens before your modified value of user-emacs-directory becomes in effect. > If I do not set user-emacs-directory, native-comp-eln-load-path stays > at its default value and the recompilation problem goes away. Then please refrain from changing the value of user-emacs-directory. > As an aside, shouldn't the default native-comp-eln-load-path be > ~/.cache/emacs/eln-cache? Cache artifacts aren't meant to be generated in > the configuration hierarchy. Sorry, I don't understand the question. What is "the configuration hierarchy"?
bug-gnu-emacs@HIDDEN:bug#77745; Package emacs.
Full text available.
Received: (at 77745) by debbugs.gnu.org; 11 Apr 2025 18:50:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 11 14:50:36 2025
Received: from localhost ([127.0.0.1]:51749 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u3JSW-0002oX-76
for submit <at> debbugs.gnu.org; Fri, 11 Apr 2025 14:50:36 -0400
Received: from mail-ua1-x936.google.com ([2607:f8b0:4864:20::936]:54457)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <bjourne@HIDDEN>) id 1u3JSU-0002oH-K0
for 77745 <at> debbugs.gnu.org; Fri, 11 Apr 2025 14:50:35 -0400
Received: by mail-ua1-x936.google.com with SMTP id
a1e0cc1a2514c-86cce5dac90so984912241.0
for <77745 <at> debbugs.gnu.org>; Fri, 11 Apr 2025 11:50:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1744397429; x=1745002229; darn=debbugs.gnu.org;
h=content-transfer-encoding:cc:to:subject:message-id:date:from
:in-reply-to:references:mime-version:from:to:cc:subject:date
:message-id:reply-to;
bh=tQmWGGFKB4cW7JzV5pJAYXteE4D8EcBErdapPPodm5s=;
b=exfdQ0ry5sbqPuYM+1bMiq++b/EdoLPbQyO2gxtxi/5pXJbr3K8gYBQgkOeT2i3CAR
MR0tf12VqdfzlcoEjd1KRVtvA3MvXP592mG8nP/ToQByfuAwDZxEhkWzxWu9aQhLF2eX
TlwH+ok4EGd+xpkRSt3qlawXcHRenuuq58dXHI8g7Enh9R1DRQZOS6ua8PW8CIEI28Kl
DVHwAf63/rIm25EpavzYgvw49YEeZhwRtRMvTpHZx49FnSLvDYchHTJjebPpnTQ347Hu
kRXsSWPcdoag7BqvVH9cohz+yCalSgOmk4Js1Fgfz173X/m27y8wR73dD0maW8J6OySb
+1eQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1744397429; x=1745002229;
h=content-transfer-encoding:cc:to:subject:message-id:date:from
:in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=tQmWGGFKB4cW7JzV5pJAYXteE4D8EcBErdapPPodm5s=;
b=lp792kqaAdcJYV2Yfgo4gNQShcUO9LHI0fB509IGYcX67tiLgdbkLnIBKR4ZGwL+hf
azSdOJtgJuJsWc0oeWFHpcT0DOJycDYyZn/CxiLoMjfrAgA7bzUYZLJp9bqXMGPDKhWR
5JPjsoncAVIChvFEfJ3p6Dc2RhslYqduuYLFjWHGN/+eUVeEsPLozTsU7XWKmdcTOOGQ
0/hq2ONGSlggsVqdHXTCrDocVzSpzdEHMx2oK5tiWDp6knVDldlJAo85M0Dy9V/MV6dW
1meOEstG2koLDo5goUh5nNCMP2VE48OugnQBZuc/OXn5XSLNrBB4efqtq9WbbiJUOyUs
4/nA==
X-Gm-Message-State: AOJu0YzLyYYtzLALMSXwxd9GGQRkR5fsTQTlZC0wj/ShPAYKk5C80DA4
HmPpmXFogIp8/+UtPi74PvWvp7IM2sbuo54q+1/MKg1ByBrZpVHPTDfvrXlPfBsyql8Cazk15XI
/TD+p+5lutfFNaW0OF/awL8ofXiLqGXzU
X-Gm-Gg: ASbGncvYR8yf2dk6oQrUgMgud21jvj0g9/NuhAigSwjGvLUZZrYB9CcrI7p5V1uZ9eO
NZaUAvWBqeODwh0qH6FEP6PCh8zDpWBAqUVeqS24fciL4X/bZbNmmYkVG0vsKsmR0K4jkNl4sI/
3KyPcugvc1CCXBeDgKRc8QCH46HM4Ft/70nQ4xiMLdUWE8bEaMfA==
X-Google-Smtp-Source: AGHT+IEb3A502wId5miXbYEtIee9rE0JFCtW0nMpop9fiv0Sn8iJJ1AV+3K17hwZk68MiPToFTj/7eBRZiGrCnd2rh0=
X-Received: by 2002:a05:6102:3f4d:b0:4bb:eb4a:fa03 with SMTP id
ada2fe7eead31-4c9e504bd76mr3222313137.23.1744397428749; Fri, 11 Apr 2025
11:50:28 -0700 (PDT)
MIME-Version: 1.0
References: <CALG+76edL6PRmODyibLDtAk6_cAy2a4JZ6dV4mRGhRO1h-WwNA@HIDDEN>
<86r01yoe8y.fsf@HIDDEN>
In-Reply-To: <86r01yoe8y.fsf@HIDDEN>
From: =?UTF-8?Q?Bj=C3=B6rn_Lindqvist?= <bjourne@HIDDEN>
Date: Fri, 11 Apr 2025 20:50:17 +0200
X-Gm-Features: ATxdqUHXiSUUloooDnsue0PuUufbSrADpWIvu15HiklQpMTtO9ncJ35h6sNorv0
Message-ID: <CALG+76fvOrn_7cRnj4PJ09-1Jsowq9iS59xeEPS0Yi2BK=ac8A@HIDDEN>
Subject: Re: bug#77745: Async native compilation runs every time I start Emacs
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 77745
Cc: 77745 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
> Do you see the *.eln files created each time the native compilation is
> triggered? If so, are these files recreated using the same hashes in
> the file name, or do the hashes change? Are the sources moved between
> the sessions, perhaps? Are you always starting the same Emacs binary,
> or do you rebuild Emacs between sessions? Did you customize the value
> of native-comp-eln-load-path from its default?
Yes. Same hashes. No. Same binary. Yes! At the top of my init.el I have
(setq user-emacs-directory "~/.config/emacs/lisp/")
causing *most* .eln files to be dumped in
~/.config/emacs/lisp/eln-cache/31.0.50-859de2ee. However, two
mysterious files are still being written to
~/.config/emacs/eln-cache/31.0.50-859de2ee (no lisp) in the path:
subr--trampoline-6d616b652d70726f63657373_make_process_0.eln
subr--trampoline-616c6c2d636f6d706c6574696f6e73_all_completions_0.eln
If I do not set user-emacs-directory, native-comp-eln-load-path stays
at its default value and the recompilation problem goes away. I'll use
that as my workaround since setting user-emacs-directory to a
non-default isn't important for me. It appears that
native-comp-eln-load-path shouldn't be touched from within init.el
because that causes weird side-effects.
As an aside, shouldn't the default native-comp-eln-load-path be
~/.cache/emacs/eln-cache? Cache artifacts aren't meant to be generated in
the configuration hierarchy.
--=20
mvh/best regards Bj=C3=B6rn Lindqvist
bug-gnu-emacs@HIDDEN:bug#77745; Package emacs.
Full text available.Received: (at 77745) by debbugs.gnu.org; 11 Apr 2025 16:27:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 11 12:27:23 2025 Received: from localhost ([127.0.0.1]:51477 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u3HDu-0001C4-RP for submit <at> debbugs.gnu.org; Fri, 11 Apr 2025 12:27:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60754) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1u3HDs-0001Bn-8m for 77745 <at> debbugs.gnu.org; Fri, 11 Apr 2025 12:27:20 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1u3HDm-0003YI-UI; Fri, 11 Apr 2025 12:27:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=a8jRo19KfJRh9fRaCxbS3z8jIXySki0bx8V60ME+5XA=; b=fXhPPurbQPZ8HybatHuG MN8nChw30za17SQ6MpqzosVf76A46w6hRtxRPvvYidEkMUKFCn3ojCHDak5UmBQubl17O+I5h/hVm 8QfQmz6B0vuLf6m8es/kbZFvh4NL63gyVKO8AKthg8cy6HsrC+ylBohO1vveCQaFaozmJf8/JC4YH UHelDS4iadX9eLWtu98kC6xDBMCZmtfJoI/otBz4xKjG2l3nAzWoO115Plh/6n40aNeb2h/kCeT7C hdq1Ot0soip5G61OnMx6mmwMiVSXx/g/D8FqsEN/jQTp/+TLJid/3fhoTOODx05UVklW5hKRexGx0 bBYGV2lk7elZyQ==; Date: Fri, 11 Apr 2025 19:27:09 +0300 Message-Id: <86r01yoe8y.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?utf-8?Q?Bj=C3=B6rn?= Lindqvist <bjourne@HIDDEN> In-Reply-To: <CALG+76edL6PRmODyibLDtAk6_cAy2a4JZ6dV4mRGhRO1h-WwNA@HIDDEN> (message from =?utf-8?Q?Bj=C3=B6rn?= Lindqvist on Fri, 11 Apr 2025 16:47:17 +0200) Subject: Re: bug#77745: Async native compilation runs every time I start Emacs References: <CALG+76edL6PRmODyibLDtAk6_cAy2a4JZ6dV4mRGhRO1h-WwNA@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77745 Cc: 77745 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Björn Lindqvist <bjourne@HIDDEN> > Date: Fri, 11 Apr 2025 16:47:17 +0200 > > The native compiler does not realize that it has already compiled the > code so it recompiles it again every time I restart > Emacs. Unfortunately, the logs don't describe *why* the compiler > thinks the source is stale so debugging the problem is difficult. I > can trigger the recompilation easily just by eagerly loading a package > in my init.el. For example, > > (use-package magit) > > will cause magit and all modules it depends on to be recompiled. I'm > using magit as an example, but the same thing happens with most other > packages too. You need to figure out why this happens, because it definitely isn't happening for others. Do you see the *.eln files created each time the native compilation is triggered? If so, are these files recreated using the same hashes in the file name, or do the hashes change? Are the sources moved between the sessions, perhaps? Are you always starting the same Emacs binary, or do you rebuild Emacs between sessions? Did you customize the value of native-comp-eln-load-path from its default? These and other questions need to be answered before we can understand why you have this problem. > I can prevent recompilation by using lazy loading: > > (use-package magit :defer t) > > Then only the file "use-package-core-b234260b-cc1d969d.eln" > gets recompiled. However, I don't think eager loading should trigger > redundant recompilations. What happens if you start "emacs -Q" and then load Magit manually by "M-x load-library"? does it get recompiled every time in that case? > > The entirety of my init.el is: > > (setq user-emacs-directory "~/.config/emacs/lisp/") > (setq package-user-dir "~/.config/emacs/packages/") > > (require 'package) > (package-initialize) > (use-package magit) > > I've tested with both Emacs 30.1 and 31.0.50 from git and it's the > same problem. Something I noticed is that the "hash" seem to be cut > short during compilation. E.g., the temporary file is called > magit-commit-664f0701-bd4a7b87KHzrEe.eln.tmp but the destination file > magit-commit-664f0701-bd4a7b87.eln. And if I load magit after init.el > it doesn't get recompiled either. > > My async compilation log: > https://gist.github.com/bjourne/8958a3918b6f0e61840a5fc10a546b4b Didn't see any errors there, so it sounds like the compilations all succeeded. Is this a recent problem, or did that always happen for you? If this started happening only lately, can you tell when?
bug-gnu-emacs@HIDDEN:bug#77745; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 11 Apr 2025 14:47:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 11 10:47:55 2025
Received: from localhost ([127.0.0.1]:51154 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u3Fff-0003KV-8D
for submit <at> debbugs.gnu.org; Fri, 11 Apr 2025 10:47:55 -0400
Received: from lists.gnu.org ([2001:470:142::17]:33748)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <bjourne@HIDDEN>) id 1u3Ffb-0003Ig-MD
for submit <at> debbugs.gnu.org; Fri, 11 Apr 2025 10:47:52 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <bjourne@HIDDEN>) id 1u3FfJ-0007EM-5o
for bug-gnu-emacs@HIDDEN; Fri, 11 Apr 2025 10:47:33 -0400
Received: from mail-qk1-x735.google.com ([2607:f8b0:4864:20::735])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from <bjourne@HIDDEN>) id 1u3FfH-0003Mr-Eo
for bug-gnu-emacs@HIDDEN; Fri, 11 Apr 2025 10:47:32 -0400
Received: by mail-qk1-x735.google.com with SMTP id
af79cd13be357-7be49f6b331so238359885a.1
for <bug-gnu-emacs@HIDDEN>; Fri, 11 Apr 2025 07:47:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1744382849; x=1744987649; darn=gnu.org;
h=content-transfer-encoding:to:subject:message-id:date:from
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=umDd9rM4rSJjZYQRy98Lvy/N57VmsOw9vGSaKh2E4a8=;
b=J4UnoLb8by6wFMzAneHkxSoO4PEXlx8JC0FhqVPgkMPeteMEWZE1PgEn/x+lJBiKZc
aw6dXyYlBOuFt/8BpwCp+d+S6sz3+L7YDwDqNfydwYxM/V+TCgUT2zqOEKTFn/Hiz8ZB
hSwpzanKMbVMHmiinK4ZyHuGi27ZSlUYHtff+8NuSU9dq3QB281LT2HnmHZxar7oLLb+
ENJNZEmQSRUWLKSWzkRPxv5Urb3HJM6l/DY9gJ43fpqxB45XhBq7VEytlgwq5hJ9f36H
o6Ei1xucTfpzb9kyH9H7x1iFQ58YCXPvIEdTP3+OXbwKD77DbFpiGOVrxKA4D9RnnjMs
POXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1744382849; x=1744987649;
h=content-transfer-encoding:to:subject:message-id:date:from
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=umDd9rM4rSJjZYQRy98Lvy/N57VmsOw9vGSaKh2E4a8=;
b=plGstGOavQRhsmPT8THQh9FSJD94Y/+JK5bVMMur2xSJaNJ0foDTHXz0wDP4WGb1ON
0x6wTsaclWvkx3tWwcf4F9UI2CK6xxNPL7xoTt0cgtBjP1jesTEUT4rJtRMtQDdBXBPC
l/5DFdUfPXKAj3GNBZz/wiRo+gRI0u2pTRXMwsXcrzC/Wt3/WTic2j2EW+tHhRLOHtrh
Ug88ui96dVhp/NjwAo+1NI5TahqCjHMIcXt2vsdjtN7fGPDGF+QtbMdsAfiyOh7UTjKm
NchYn51oKUpiywQCjcI5qQW3m3kK9gVsm0Oz79CgO2LnoBdPNszuarV8/otF7eowbci0
foNQ==
X-Gm-Message-State: AOJu0Yw7DR1Crc8nR4UuDQkgjGn3Au2u+7rPIuHN4nbvNVTIfCzoaY0x
0lfR0l9M2YrfZB5tYnHhqWcvnzXvpZSuI/c141gc6Qh4soKOX0F60cOOvAg5DDJz528wKQFeT3e
p728SWAT7R/RQx9UpW/XOXaaso9yuhm2u
X-Gm-Gg: ASbGncswp3fD8re1K9nPIlFx9qwS3wt41bEd/LsbdUuF4tk64xBGbzHIu2HPe/Aj+Yo
OoKY7Mt6v4Fq6J7gftYLFQfZMkQzPbGOrSpYOQezBLrwB1w/yAibC2YAeUX+42bmCOUiHwbFLIY
mD98YRlTw/Rfww9P/V+jIEHmDCqxlhZJk8pQFkkrgIcBoaGZgwaikwAHs+KzIx
X-Google-Smtp-Source: AGHT+IFiFOGFuBuflYAiZWayA4TA4BXWCZkIVL/eE7VkxslFuG9oagUYc3W70eEVFie3XhM0y9rbva8PG/HCChVrnf8=
X-Received: by 2002:a05:620a:44d1:b0:7c5:59e1:f0d with SMTP id
af79cd13be357-7c7af115afcmr437838185a.39.1744382849219; Fri, 11 Apr 2025
07:47:29 -0700 (PDT)
MIME-Version: 1.0
From: =?UTF-8?Q?Bj=C3=B6rn_Lindqvist?= <bjourne@HIDDEN>
Date: Fri, 11 Apr 2025 16:47:17 +0200
X-Gm-Features: ATxdqUG9wR0VHngYhFwGuK4UmKtL7K6G7uvMOxUw5Ch6iUsXl5RPsXEVrdpGUrk
Message-ID: <CALG+76edL6PRmODyibLDtAk6_cAy2a4JZ6dV4mRGhRO1h-WwNA@HIDDEN>
Subject: Async native compilation runs every time I start Emacs
To: bug-gnu-emacs@HIDDEN
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=2607:f8b0:4864:20::735;
envelope-from=bjourne@HIDDEN; helo=mail-qk1-x735.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)
The native compiler does not realize that it has already compiled the
code so it recompiles it again every time I restart
Emacs. Unfortunately, the logs don't describe *why* the compiler
thinks the source is stale so debugging the problem is difficult. I
can trigger the recompilation easily just by eagerly loading a package
in my init.el. For example,
(use-package magit)
will cause magit and all modules it depends on to be recompiled. I'm
using magit as an example, but the same thing happens with most other
packages too. I can prevent recompilation by using lazy loading:
(use-package magit :defer t)
Then only the file "use-package-core-b234260b-cc1d969d.eln"
gets recompiled. However, I don't think eager loading should trigger
redundant recompilations.
The entirety of my init.el is:
(setq user-emacs-directory "~/.config/emacs/lisp/")
(setq package-user-dir "~/.config/emacs/packages/")
(require 'package)
(package-initialize)
(use-package magit)
I've tested with both Emacs 30.1 and 31.0.50 from git and it's the
same problem. Something I noticed is that the "hash" seem to be cut
short during compilation. E.g., the temporary file is called
magit-commit-664f0701-bd4a7b87KHzrEe.eln.tmp but the destination file
magit-commit-664f0701-bd4a7b87.eln. And if I load magit after init.el
it doesn't get recompiled either.
My async compilation log:
https://gist.github.com/bjourne/8958a3918b6f0e61840a5fc10a546b4b
--=20
mvh/best regards Bj=C3=B6rn Lindqvist
Björn Lindqvist <bjourne@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#77745; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.