From unknown Sun Jun 22 04:29:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS) Resent-From: Matthew Bauer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Jun 2021 03:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 48994 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: 48994@debbugs.gnu.org Cc: Andrea Corallo X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.162355400031807 (code B ref -1); Sun, 13 Jun 2021 03:14:01 +0000 Received: (at submit) by debbugs.gnu.org; 13 Jun 2021 03:13:20 +0000 Received: from localhost ([127.0.0.1]:42415 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lsGYq-0008Gx-6X for submit@debbugs.gnu.org; Sat, 12 Jun 2021 23:13:20 -0400 Received: from lists.gnu.org ([209.51.188.17]:52972) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lsGYo-0008Gq-Sm for submit@debbugs.gnu.org; Sat, 12 Jun 2021 23:13:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60452) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lsGYo-00081V-N2 for bug-gnu-emacs@gnu.org; Sat, 12 Jun 2021 23:13:18 -0400 Received: from mail-ot1-x32a.google.com ([2607:f8b0:4864:20::32a]:34484) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lsGYm-0008Mu-Sb for bug-gnu-emacs@gnu.org; Sat, 12 Jun 2021 23:13:18 -0400 Received: by mail-ot1-x32a.google.com with SMTP id w22-20020a0568304116b02904060c6415c7so5002602ott.1 for ; Sat, 12 Jun 2021 20:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version; bh=+6dcHQuS18Mh3ncvCFU+2MoyZ+/txQfEO3/sqpovXts=; b=t8rBJdqh4H2f4Iev7ZiFbYqZX96yRlJnXXAg1vPZYwoQgLSoT1pn5yeYlbp8k+AVJk 4FjxQlS2iiz7AyZcJnfA3GP3vjxKrOyouo4zEKWaNPmIWIERBznXkURQFEtWhtfBY/2Q 7AIjNC3+Z52oFihjyANDijIzMOoOZljz9LB2SdfWk4tYV4loOKRLEwY71Equ5DlyFqBT pKo7FiOhDXw521mOc8/h4/NSvJ4ww55jMmu7tAxKIDSRxVYcxHUkrnQ2yaGtC1GCUJd9 mCP64eQD7Q5ui+DrAJbRVrBiztS7xvx5EN6nknZxrjIxQ/VNKgHHaYJ1rsm5A6SkjD8e /VUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version; bh=+6dcHQuS18Mh3ncvCFU+2MoyZ+/txQfEO3/sqpovXts=; b=cJgA9DVSV3Av13mwzD1SpW+lVrkkpa7sXYU3BbmblTBn/HYey3NisTcmA2m3hCHDHD kamOpL8aeqAzTqNTIbMb/GfzfmDKsbaFrTyJBOOJZP7wXIGFAuXilNwBEoVJvIMhmzUf U4VmyCQBxPE6HxnBcN7wYGWcFcuOByWzGC36grfuQMo9YifuKdZs5nSlby0oYR/8UrB3 M9rwdo/hbqnBJXtFI3YUwxusmyWrP+OchpOoU9vAXAxBwPWbmp2M/X0Tc/CvZt/07RkA bLgdFWGci5EmsxkQSaTee2s8ZvV9/ueqCxZA1hcduXlVOLT8CiIqH0Mzdh5E7kq3Qkja kzUw== X-Gm-Message-State: AOAM532kyNgXwS+LWvTRF4vEu8Gj/B2qDsGsu5gSfJSn9mCmCq84eoCC 9tK1+kUxm9OMwIhnE7Nai9U= X-Google-Smtp-Source: ABdhPJzwn598XAFUdKeOYiwuIo39d9dgJv3zn33P5BUvfz5MoOJh3ZuPAej2fBCYO1Ga9S8Hlcr6Eg== X-Received: by 2002:a9d:6f0d:: with SMTP id n13mr8858393otq.168.1623553994849; Sat, 12 Jun 2021 20:13:14 -0700 (PDT) Received: from mac-mini.lan ([2605:a601:ac7b:7f00:2d69:8908:249:46b8]) by smtp.gmail.com with ESMTPSA id w8sm2324729otk.16.2021.06.12.20.13.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 12 Jun 2021 20:13:14 -0700 (PDT) From: Matthew Bauer Date: Sat, 12 Jun 2021 22:13:13 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=2607:f8b0:4864:20::32a; envelope-from=mjbauer95@gmail.com; helo=mail-ot1-x32a.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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_ENVFROM_END_DIGIT=0.25, 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.1 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is similar to bug#48497, but appears to still happen even after commit 3f207753a0. The basic problem is that the installed lisp path does not match either of the search expressions in comp-el-to-eln-rel-filename, meaning that native lisp needs to be recompiled needlessly. The problem seems to come from PATH_REL_LOADSEARCH being set for me (on macOS) to Contents/Resources/lisp, but the lisp files actually being installed to /nix/store/...-emacs-gcc-20210612.0/share/emacs/28.0.50/lisp (path generated by Nix). As a result, comp-el-to-eln-rel-filename used the filename comp-034d3699-516ce4bf.eln for comp.el.gz where 516ce4bf is the md5sum of the contents of comp.el and 034d3699 is the md5sum of the full path of comp.el, not of //emacs-lisp/comp.el (7672a6ed), which is what Emacs installs. To fix this, I propose using PATH_LOADSEARCH in addition to PATH_REL_LOADSEARCH so that we can catch both types of macOS installs (.app and unix). I=E2=80=99ve attached a patch which implements this, adding relative and absolute loadsearch resolution. - Matthew --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Use-PATH_LOADSEARCH-to-get-absolute-path-of-native-c.patch >From 32022ee8d977196c72ad42d89d23142a6e59ff8e Mon Sep 17 00:00:00 2001 From: Matthew Bauer Date: Sat, 12 Jun 2021 00:37:28 -0500 Subject: [PATCH] Use PATH_LOADSEARCH to get absolute path of native comp We need to so that /usr/local/share/emacs/28.0.50/lisp/emacs-lisp/comp.el becomes: //emacs-lisp/comp.el which is what we install eln files as. --- src/comp.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/src/comp.c b/src/comp.c index 056d0860d8..8ccd99d583 100644 --- a/src/comp.c +++ b/src/comp.c @@ -4049,12 +4049,14 @@ DEFUN ("comp-el-to-eln-rel-filename", Fcomp_el_to_eln_rel_filename, As installing .eln files compiled during the build changes their absolute path we need an hashing mechanism that is not sensitive - to that. For this we replace if match PATH_DUMPLOADSEARCH or - *PATH_REL_LOADSEARCH with '//' before computing the hash. */ + to that. For this we replace if match PATH_DUMPLOADSEARCH, + PATH_REL_LOADSEARCH, or PATH_LOADSEARCH with '//' before + computing the hash. */ if (NILP (loadsearch_re_list)) { - Lisp_Object sys_re = + Lisp_Object sys_abs_re = Fregexp_quote (build_string (PATH_LOADSEARCH "/")); + Lisp_Object sys_rel_re = concat2 (build_string ("\\`[[:ascii:]]+"), Fregexp_quote (build_string ("/" PATH_REL_LOADSEARCH "/"))); Lisp_Object dump_load_search = @@ -4062,7 +4064,7 @@ DEFUN ("comp-el-to-eln-rel-filename", Fcomp_el_to_eln_rel_filename, #ifdef WINDOWSNT dump_load_search = Fw32_long_file_name (dump_load_search); #endif - loadsearch_re_list = list2 (sys_re, Fregexp_quote (dump_load_search)); + loadsearch_re_list = list3 (sys_abs_re, sys_rel_re, Fregexp_quote (dump_load_search)); } Lisp_Object lds_re_tail = loadsearch_re_list; -- 2.29.2 --=-=-=-- From unknown Sun Jun 22 04:29:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Jun 2021 06:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48994 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Matthew Bauer , Alan Third Cc: 48994@debbugs.gnu.org, akrl@sdf.org Received: via spool by 48994-submit@debbugs.gnu.org id=B48994.162356624819339 (code B ref 48994); Sun, 13 Jun 2021 06:38:02 +0000 Received: (at 48994) by debbugs.gnu.org; 13 Jun 2021 06:37:28 +0000 Received: from localhost ([127.0.0.1]:42496 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lsJkN-00051r-QZ for submit@debbugs.gnu.org; Sun, 13 Jun 2021 02:37:28 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47580) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lsJkM-00051c-N1 for 48994@debbugs.gnu.org; Sun, 13 Jun 2021 02:37:26 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:35196) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lsJkG-0002Kh-HK; Sun, 13 Jun 2021 02:37:20 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3945 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lsJkG-0005RT-5O; Sun, 13 Jun 2021 02:37:20 -0400 Date: Sun, 13 Jun 2021 09:37:15 +0300 Message-Id: <83y2be6zj8.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Matthew Bauer on Sat, 12 Jun 2021 22:13:13 -0500) References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Matthew Bauer > Date: Sat, 12 Jun 2021 22:13:13 -0500 > Cc: Andrea Corallo > > This is similar to bug#48497, but appears to still happen even after > commit 3f207753a0. > > The basic problem is that the installed lisp path does not match either > of the search expressions in comp-el-to-eln-rel-filename, meaning that > native lisp needs to be recompiled needlessly. > > The problem seems to come from PATH_REL_LOADSEARCH being set for me (on > macOS) to Contents/Resources/lisp, but the lisp files actually being > installed to > /nix/store/...-emacs-gcc-20210612.0/share/emacs/28.0.50/lisp (path > generated by Nix). As a result, comp-el-to-eln-rel-filename used the > filename comp-034d3699-516ce4bf.eln for comp.el.gz where 516ce4bf is the > md5sum of the contents of comp.el and 034d3699 is the md5sum of the full > path of comp.el, not of //emacs-lisp/comp.el (7672a6ed), which is what > Emacs installs. > > To fix this, I propose using PATH_LOADSEARCH in addition to > PATH_REL_LOADSEARCH so that we can catch both types of macOS installs > (.app and unix). I’ve attached a patch which implements this, adding > relative and absolute loadsearch resolution. Thanks. Alan, any comments? And could you explain to this macOS-illiterate why this mess happens on macOS? In any case, if this only happens on macOS, I see no reason to run the additional code on other systems, it's just waste of cycles. From unknown Sun Jun 22 04:29:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS) Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Jun 2021 16:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48994 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: 48994@debbugs.gnu.org, Matthew Bauer , akrl@sdf.org Received: via spool by 48994-submit@debbugs.gnu.org id=B48994.16236022888818 (code B ref 48994); Sun, 13 Jun 2021 16:39:01 +0000 Received: (at 48994) by debbugs.gnu.org; 13 Jun 2021 16:38:08 +0000 Received: from localhost ([127.0.0.1]:44285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lsT7f-0002I9-Ow for submit@debbugs.gnu.org; Sun, 13 Jun 2021 12:38:08 -0400 Received: from outbound.soverin.net ([116.202.65.218]:49379) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lsT7d-0002HY-Ss for 48994@debbugs.gnu.org; Sun, 13 Jun 2021 12:38:06 -0400 Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id CBAE9600C1; Sun, 13 Jun 2021 16:37:59 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1623602278; bh=T5FW9FM6+J41tjLT3rLFNINoxIqS5Xz2hR3tCwSWuos=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=q9H3KAeTWaawpxWSBy+0yc6E30DnPB6cYe2RnxZ5XX+HBSDpG6+OobaCoF2KCpTW6 /j06MUuGmgErH+f/SrgyfiAHqOY3acWUCzBl+z4i3Ql+xvAnDRnH+qXdA+LJRQImp6 HShPEsZjFzDDlFRlCyFQJziqRz16PJSvAMapYZeFkDHlaJjZF/dQ35dEc91A9l7Aoy VEE2LTlarHAqXTXz7o6Hs6C92a/p6aM4G9y7CvFsVIAuFHuULSMe5eA8WyFgVRNeEp HymTSMEUEVoHK5WjrWd9C6goFsv1I2fGKjnm6MqFxsN9YDGZ+GoktD/vaNQQj5TqDo qmkL2uOewykcA== Received: from alan by faroe.holly.idiocy.org with local (Exim 4.94.2) (envelope-from ) id 1lsT7T-00208v-Lg; Sun, 13 Jun 2021 17:37:55 +0100 Date: Sun, 13 Jun 2021 17:37:55 +0100 From: Alan Third Message-ID: Mail-Followup-To: Alan Third , Eli Zaretskii , Matthew Bauer , 48994@debbugs.gnu.org, akrl@sdf.org References: <83y2be6zj8.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <83y2be6zj8.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On Sun, Jun 13, 2021 at 09:37:15AM +0300, Eli Zaretskii wrote: > > From: Matthew Bauer > > Date: Sat, 12 Jun 2021 22:13:13 -0500 > > Cc: Andrea Corallo > > > > This is similar to bug#48497, but appears to still happen even after > > commit 3f207753a0. > > > > The basic problem is that the installed lisp path does not match either > > of the search expressions in comp-el-to-eln-rel-filename, meaning that > > native lisp needs to be recompiled needlessly. > > > > The problem seems to come from PATH_REL_LOADSEARCH being set for me (on > > macOS) to Contents/Resources/lisp, but the lisp files actually being > > installed to > > /nix/store/...-emacs-gcc-20210612.0/share/emacs/28.0.50/lisp (path > > generated by Nix). As a result, comp-el-to-eln-rel-filename used the > > filename comp-034d3699-516ce4bf.eln for comp.el.gz where 516ce4bf is the > > md5sum of the contents of comp.el and 034d3699 is the md5sum of the full > > path of comp.el, not of //emacs-lisp/comp.el (7672a6ed), which is what > > Emacs installs. > > > > To fix this, I propose using PATH_LOADSEARCH in addition to > > PATH_REL_LOADSEARCH so that we can catch both types of macOS installs > > (.app and unix). I’ve attached a patch which implements this, adding > > relative and absolute loadsearch resolution. > > Thanks. > > Alan, any comments? I suggested previously we handle this like we do the other install paths (see ns_etc_path, ns_exec_path and ns_load_path in nsterm.m), but Andrea didn't like that solution. > And could you explain to this macOS-illiterate why this mess happens > on macOS? It's because we support both a relocatable application format and a normal unix style install. In the .app case the path to the installed files has to be configured at run-time (although I think Andrea used a directory relative to the executable), but in the unix case it's hard-coded. FWIW, we will have exactly the same problems with GNUstep builds, because they use the same .app format. -- Alan Third From unknown Sun Jun 22 04:29:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Jun 2021 17:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48994 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Alan Third Cc: 48994@debbugs.gnu.org, mjbauer95@gmail.com, akrl@sdf.org Received: via spool by 48994-submit@debbugs.gnu.org id=B48994.162360488612852 (code B ref 48994); Sun, 13 Jun 2021 17:22:02 +0000 Received: (at 48994) by debbugs.gnu.org; 13 Jun 2021 17:21:26 +0000 Received: from localhost ([127.0.0.1]:44321 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lsTna-0003LD-94 for submit@debbugs.gnu.org; Sun, 13 Jun 2021 13:21:26 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39932) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lsTnY-0003L0-JW for 48994@debbugs.gnu.org; Sun, 13 Jun 2021 13:21:25 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48480) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lsTnR-0003Cp-UP; Sun, 13 Jun 2021 13:21:17 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4391 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lsTnR-0002eu-H8; Sun, 13 Jun 2021 13:21:17 -0400 Date: Sun, 13 Jun 2021 20:21:11 +0300 Message-Id: <83bl897kag.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Alan Third on Sun, 13 Jun 2021 17:37:55 +0100) References: <83y2be6zj8.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 13 Jun 2021 17:37:55 +0100 > From: Alan Third > Cc: Matthew Bauer , 48994@debbugs.gnu.org, > akrl@sdf.org > > I suggested previously we handle this like we do the other install > paths (see ns_etc_path, ns_exec_path and ns_load_path in nsterm.m), > but Andrea didn't like that solution. Can you point me to that discussion, please? From unknown Sun Jun 22 04:29:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS) Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Jun 2021 19:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48994 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: 48994@debbugs.gnu.org, mjbauer95@gmail.com, akrl@sdf.org Received: via spool by 48994-submit@debbugs.gnu.org id=B48994.16236126292173 (code B ref 48994); Sun, 13 Jun 2021 19:31:02 +0000 Received: (at 48994) by debbugs.gnu.org; 13 Jun 2021 19:30:29 +0000 Received: from localhost ([127.0.0.1]:44393 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lsVoS-0000Yz-Ue for submit@debbugs.gnu.org; Sun, 13 Jun 2021 15:30:29 -0400 Received: from outbound.soverin.net ([116.202.65.218]:45781) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lsVoO-0000Yj-9U for 48994@debbugs.gnu.org; Sun, 13 Jun 2021 15:30:27 -0400 Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 79915600C1; Sun, 13 Jun 2021 19:30:18 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1623612617; bh=jNFF9YSh/BWE3oUURFYGbz0fe/kDV1UM0kBJ36IcEL0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZjuVjmFQwq5ioYoFse25p2rs23zV/62Ay964neMERPzfNeQ/zLYfPY2TNejmBONnl IaxcbCxN6sGNrbbVAed3RrYFRIpwEYPJmdXBgipOFcda/krne1+uzDF8GLhigwddHt JS4smci8SFkTXrAzaFOzWUaLS+HZ7Om/3OkeGYAmHC/zviAFkELyJ2wcju1w1sNXkJ fP+4/y198sznJYFcDX+0ESzV29dI32G7khE/vKhy9n4zOA2gXq9CgSEpkFtaW1wx61 n+PWiDRBES4qXJchhSBYvkZM40OTKeo44eqMs+tdv/71rKDla5qdDCffEwwp6AQPl7 y1vW4xCIokqUA== Received: from alan by faroe.holly.idiocy.org with local (Exim 4.94.2) (envelope-from ) id 1lsVoD-0020MY-Qp; Sun, 13 Jun 2021 20:30:13 +0100 Date: Sun, 13 Jun 2021 20:30:13 +0100 From: Alan Third Message-ID: Mail-Followup-To: Alan Third , Eli Zaretskii , mjbauer95@gmail.com, 48994@debbugs.gnu.org, akrl@sdf.org References: <83y2be6zj8.fsf@gnu.org> <83bl897kag.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83bl897kag.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On Sun, Jun 13, 2021 at 08:21:11PM +0300, Eli Zaretskii wrote: > > Date: Sun, 13 Jun 2021 17:37:55 +0100 > > From: Alan Third > > Cc: Matthew Bauer , 48994@debbugs.gnu.org, > > akrl@sdf.org > > > > I suggested previously we handle this like we do the other install > > paths (see ns_etc_path, ns_exec_path and ns_load_path in nsterm.m), > > but Andrea didn't like that solution. > > Can you point me to that discussion, please? There isn't much in the way of actual discussion. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47558#44 -- Alan Third From unknown Sun Jun 22 04:29:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Jun 2021 12:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48994 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Alan Third Cc: 48994@debbugs.gnu.org, mjbauer95@gmail.com, akrl@sdf.org Received: via spool by 48994-submit@debbugs.gnu.org id=B48994.162367457610824 (code B ref 48994); Mon, 14 Jun 2021 12:43:02 +0000 Received: (at 48994) by debbugs.gnu.org; 14 Jun 2021 12:42:56 +0000 Received: from localhost ([127.0.0.1]:45238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lslvb-0002oV-Na for submit@debbugs.gnu.org; Mon, 14 Jun 2021 08:42:55 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45308) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lslva-0002oJ-8L for 48994@debbugs.gnu.org; Mon, 14 Jun 2021 08:42:54 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42708) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lslvU-0001Zb-2T; Mon, 14 Jun 2021 08:42:48 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4093 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lslvT-0002ES-LX; Mon, 14 Jun 2021 08:42:48 -0400 Date: Mon, 14 Jun 2021 15:42:41 +0300 Message-Id: <8335tk7h32.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Alan Third on Sun, 13 Jun 2021 20:30:13 +0100) References: <83y2be6zj8.fsf@gnu.org> <83bl897kag.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 13 Jun 2021 20:30:13 +0100 > From: Alan Third > Cc: mjbauer95@gmail.com, 48994@debbugs.gnu.org, akrl@sdf.org > > On Sun, Jun 13, 2021 at 08:21:11PM +0300, Eli Zaretskii wrote: > > > Date: Sun, 13 Jun 2021 17:37:55 +0100 > > > From: Alan Third > > > Cc: Matthew Bauer , 48994@debbugs.gnu.org, > > > akrl@sdf.org > > > > > > I suggested previously we handle this like we do the other install > > > paths (see ns_etc_path, ns_exec_path and ns_load_path in nsterm.m), > > > but Andrea didn't like that solution. > > > > Can you point me to that discussion, please? > > There isn't much in the way of actual discussion. > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47558#44 Hmm... that problem was solved, though? So how come it comes up once again? In the tree that you described in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47558#23 can you where is each of the following: . the Emacs binary . the .pdmp file . the auxiliary executables (hexl, movemail) . the *.eln files Also, I understand that the "normal" Unix-style install has the usual tree hierarchy rooted at /usr or /usr/local, and there everything "just works"? If so, when (at configure time, at installation time, at some other time?) is the decision made whether the install will be one or the other? The issue finding the *.eln files is tightly coupled with how Emacs finds the .pdmp file, so we must consider these together to be sure the solutions don't break. Thanks. From unknown Sun Jun 22 04:29:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS) Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Jun 2021 18:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48994 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: 48994@debbugs.gnu.org, mjbauer95@gmail.com, akrl@sdf.org Received: via spool by 48994-submit@debbugs.gnu.org id=B48994.162369556717683 (code B ref 48994); Mon, 14 Jun 2021 18:33:01 +0000 Received: (at 48994) by debbugs.gnu.org; 14 Jun 2021 18:32:47 +0000 Received: from localhost ([127.0.0.1]:47805 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lsrOB-0004b9-5G for submit@debbugs.gnu.org; Mon, 14 Jun 2021 14:32:47 -0400 Received: from outbound.soverin.net ([116.202.65.218]:60437) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lsrO9-0004as-FA for 48994@debbugs.gnu.org; Mon, 14 Jun 2021 14:32:46 -0400 Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 539D760052; Mon, 14 Jun 2021 18:32:39 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1623695558; bh=NvBRgpIM0jbjcd7C5rfIXz87+JNXDCpF3jSjLju0fq0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Shv5yJZaXMyKGMYmEpwA+vGjzETe0FQjYKag2Z/GiWTDTDpvTfsl6txAZdbwkxWEx ZstPrvUphGEe0Ef84MiK+cq6+o2bCk1wjOEPu0yegIIfTX+K2p8z/Q4m/mF43hEuan 3Uq315VJ/lmqwXpApeGxx+Js7FmhWJPwa2d6xsR9PSaa0GY9640PTYo/F6yzlAs2Ni 87xWd3dLtAuY8sZjMLgdGGWvETvAMTAvxjKRVOvhsItRipnvyTmB1irFjL0SgdwEeD CCswtWvqPdkEMVXe3ACCvPrmUui9hAryH8NQnbAU+n1fL/vzL11oo5SyODMDOsOw/R HWAyncVhyItCA== Received: from alan by faroe.holly.idiocy.org with local (Exim 4.94.2) (envelope-from ) id 1lsrO0-0021jG-W4; Mon, 14 Jun 2021 19:32:37 +0100 Date: Mon, 14 Jun 2021 19:32:36 +0100 From: Alan Third Message-ID: Mail-Followup-To: Alan Third , Eli Zaretskii , 48994@debbugs.gnu.org, mjbauer95@gmail.com, akrl@sdf.org References: <83y2be6zj8.fsf@gnu.org> <83bl897kag.fsf@gnu.org> <8335tk7h32.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8335tk7h32.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On Mon, Jun 14, 2021 at 03:42:41PM +0300, Eli Zaretskii wrote: > > Date: Sun, 13 Jun 2021 20:30:13 +0100 > > From: Alan Third > > Cc: mjbauer95@gmail.com, 48994@debbugs.gnu.org, akrl@sdf.org > > > > On Sun, Jun 13, 2021 at 08:21:11PM +0300, Eli Zaretskii wrote: > > > > Date: Sun, 13 Jun 2021 17:37:55 +0100 > > > > From: Alan Third > > > > Cc: Matthew Bauer , 48994@debbugs.gnu.org, > > > > akrl@sdf.org > > > > > > > > I suggested previously we handle this like we do the other install > > > > paths (see ns_etc_path, ns_exec_path and ns_load_path in nsterm.m), > > > > but Andrea didn't like that solution. > > > > > > Can you point me to that discussion, please? > > > > There isn't much in the way of actual discussion. > > > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47558#44 > > Hmm... that problem was solved, though? So how come it comes up once > again? It was solved for the .app use case, perhaps that broke the Unix-style install case? I have to admit that I don't really understand this and have a very limited understanding of how the makefiles build the .app or not. > In the tree that you described in > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47558#23 > > can you where is each of the following: > > . the Emacs binary Emacs.app/Contents/MacOS/Emacs (This is different on GNUstep builds. I think it's Emacs.app/Contents/Emacs.) > . the .pdmp file The same location as the binary. That was my change and it was done that way because I don't really understand any of this but that happened to work. > . the auxiliary executables (hexl, movemail) I believe they're in Emacs.app/Contents/MacOS/libexec. (Again, this is different on GNUstep.) > . the *.eln files Emacs.app/Contents/Resources/native-elisp, or something. I'm not at a Mac to check right now, but definitely under Resources. > Also, I understand that the "normal" Unix-style install has the usual > tree hierarchy rooted at /usr or /usr/local, and there everything > "just works"? If so, when (at configure time, at installation time, > at some other time?) is the decision made whether the install will be > one or the other? I believe there's a ./configure flag. But like I said before, for the other paths there's a run-time check, so I'm not sure how it all ties together. -- Alan Third From unknown Sun Jun 22 04:29:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Jun 2021 19:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48994 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Alan Third Cc: 48994@debbugs.gnu.org, mjbauer95@gmail.com, akrl@sdf.org Received: via spool by 48994-submit@debbugs.gnu.org id=B48994.162369840822087 (code B ref 48994); Mon, 14 Jun 2021 19:21:01 +0000 Received: (at 48994) by debbugs.gnu.org; 14 Jun 2021 19:20:08 +0000 Received: from localhost ([127.0.0.1]:47830 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lss7z-0005kA-MB for submit@debbugs.gnu.org; Mon, 14 Jun 2021 15:20:07 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43874) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lss7y-0005jb-AM for 48994@debbugs.gnu.org; Mon, 14 Jun 2021 15:20:07 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55258) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lss7p-0005Ns-Fa; Mon, 14 Jun 2021 15:19:57 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1201 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lss7o-0000iS-Md; Mon, 14 Jun 2021 15:19:57 -0400 Date: Mon, 14 Jun 2021 22:19:50 +0300 Message-Id: <835yyg5k4p.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Alan Third on Mon, 14 Jun 2021 19:32:36 +0100) References: <83y2be6zj8.fsf@gnu.org> <83bl897kag.fsf@gnu.org> <8335tk7h32.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 14 Jun 2021 19:32:36 +0100 > From: Alan Third > Cc: 48994@debbugs.gnu.org, mjbauer95@gmail.com, akrl@sdf.org > > > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47558#44 > > > > Hmm... that problem was solved, though? So how come it comes up once > > again? > > It was solved for the .app use case, perhaps that broke the Unix-style > install case? Could very well be, see below. > I have to admit that I don't really understand this and have a very > limited understanding of how the makefiles build the .app or not. My primary worry is not the Makefiles, it's what the installed Emacs does upon startup to find its requisite files. > > . the Emacs binary > > Emacs.app/Contents/MacOS/Emacs > > (This is different on GNUstep builds. I think it's > Emacs.app/Contents/Emacs.) > > > . the .pdmp file > > The same location as the binary. That was my change and it was done > that way because I don't really understand any of this but that > happened to work. If the pdumper file is near the binary, I think Emacs will decide it's running uninstalled, and will look for the *.eln files in ../native-lisp relative to where the binary lives. Which is not necessarily what you want, AFAIU. > > . the auxiliary executables (hexl, movemail) > > I believe they're in Emacs.app/Contents/MacOS/libexec. > > (Again, this is different on GNUstep.) > > > . the *.eln files > > Emacs.app/Contents/Resources/native-elisp, or something. I'm not at a > Mac to check right now, but definitely under Resources. OK, please tell after you find out. > > Also, I understand that the "normal" Unix-style install has the usual > > tree hierarchy rooted at /usr or /usr/local, and there everything > > "just works"? You didn't answer this one. Are we using the Unix-style hierarchy in this case, i.e.: . Emacs binary in /usr/bin . the .pdmp file in /usr/libexec/emacs/VERSION/ARCHITECTURE . the *eln files in /usr/lib/emacs/VERSION/native-lisp ? > > If so, when (at configure time, at installation time, > > at some other time?) is the decision made whether the install will be > > one or the other? > > I believe there's a ./configure flag. But like I said before, for the > other paths there's a run-time check, so I'm not sure how it all ties > together. Which run-time check did you have in mind? From unknown Sun Jun 22 04:29:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS) Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Jun 2021 18:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48994 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: 48994@debbugs.gnu.org, mjbauer95@gmail.com, akrl@sdf.org Received: via spool by 48994-submit@debbugs.gnu.org id=B48994.162386792426801 (code B ref 48994); Wed, 16 Jun 2021 18:26:01 +0000 Received: (at 48994) by debbugs.gnu.org; 16 Jun 2021 18:25:24 +0000 Received: from localhost ([127.0.0.1]:53317 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ltaE7-0006yD-JU for submit@debbugs.gnu.org; Wed, 16 Jun 2021 14:25:23 -0400 Received: from [217.169.17.33] (port=51795 helo=breton.holly.idiocy.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ltaE5-0006xx-KL for 48994@debbugs.gnu.org; Wed, 16 Jun 2021 14:25:22 -0400 Received: by breton.holly.idiocy.org (Postfix, from userid 501) id 6028A202C9396E; Wed, 16 Jun 2021 19:25:14 +0100 (BST) Date: Wed, 16 Jun 2021 19:25:14 +0100 From: Alan Third Message-ID: Mail-Followup-To: Alan Third , Eli Zaretskii , 48994@debbugs.gnu.org, mjbauer95@gmail.com, akrl@sdf.org References: <83y2be6zj8.fsf@gnu.org> <83bl897kag.fsf@gnu.org> <8335tk7h32.fsf@gnu.org> <835yyg5k4p.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <835yyg5k4p.fsf@gnu.org> X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Mon, Jun 14, 2021 at 10:19:50PM +0300, Eli Zaretskii wrote: > > I have to admit that I don't really understand this and have a very > > limited understanding of how the makefiles build the .app or [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_NONE SPF: sender does not publish an SPF Record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) On Mon, Jun 14, 2021 at 10:19:50PM +0300, Eli Zaretskii wrote: > > I have to admit that I don't really understand this and have a very > > limited understanding of how the makefiles build the .app or not. > > My primary worry is not the Makefiles, it's what the installed Emacs > does upon startup to find its requisite files. I've done a lot of digging about and it looks like a bit of a mess, frankly. configure hard-codes "lispdirrel" to Contents/Resources/lisp, which is obviously wrong on a Unix style install, but is only "correct" on a bundled app install because argv0 is set to the root of the app bundle instead of the actual executable. I don't know why argv0 is set that way, but it must be how NS apps work because I haven't yet seen any code changing it yet. The other place that's causing trouble is this wee bit in emacs.c: /* Assume the Emacs binary lives in a sibling directory as set up by the default installation configuration. */ const char *go_up = "../../../../bin/"; Which I assume works correctly in a Unix style install but doesn't work in an app bundle install. I'm feeling that perhaps we should expose the ns_self_contained variable from configure/makefile to the C code so we can do different things in a couple of places depending on what type of install we're using. Trying to use the same code for both seems rather more difficult than it needs to be. > > > . the Emacs binary > > > > Emacs.app/Contents/MacOS/Emacs > > > > (This is different on GNUstep builds. I think it's > > Emacs.app/Contents/Emacs.) > > > > > . the .pdmp file > > > > The same location as the binary. That was my change and it was done > > that way because I don't really understand any of this but that > > happened to work. > > If the pdumper file is near the binary, I think Emacs will decide it's > running uninstalled, and will look for the *.eln files in > ../native-lisp relative to where the binary lives. Which is not > necessarily what you want, AFAIU. That's easy enough to change. If I put it in the libexec directory it works just as well. > > > . the auxiliary executables (hexl, movemail) > > > > I believe they're in Emacs.app/Contents/MacOS/libexec. > > > > (Again, this is different on GNUstep.) > > > > > . the *.eln files > > > > Emacs.app/Contents/Resources/native-elisp, or something. I'm not at a > > Mac to check right now, but definitely under Resources. > > OK, please tell after you find out. Yes, in Emacs.app/Contents/Resources/native-elisp, however that's easy to change as well. > > > Also, I understand that the "normal" Unix-style install has the usual > > > tree hierarchy rooted at /usr or /usr/local, and there everything > > > "just works"? > > You didn't answer this one. Are we using the Unix-style hierarchy in > this case, i.e.: > > . Emacs binary in /usr/bin > . the .pdmp file in /usr/libexec/emacs/VERSION/ARCHITECTURE > . the *eln files in /usr/lib/emacs/VERSION/native-lisp > > ? Sorry, I must've missed it. Yes, a normal Unix style install should be like that. However the OP appears to be using a Unix style install with a different install prefix and is getting app bundle install paths in his errors, specifically Contents/Resources/lisp, which I mentioned at the top of the email. > > > If so, when (at configure time, at installation time, > > > at some other time?) is the decision made whether the install will be > > > one or the other? > > > > I believe there's a ./configure flag. But like I said before, for the > > other paths there's a run-time check, so I'm not sure how it all ties > > together. > > Which run-time check did you have in mind? ns_exec_path, and friends. They return the app bundle paths if the directories exist, and nil otherwise, then the code that calls them modifies the search paths depending on the result. I think I can probably fix this now, hopefully without breaking anything... ;) But any observations/recommendations will be gratefully received. -- Alan Third From unknown Sun Jun 22 04:29:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Jun 2021 18:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48994 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Alan Third Cc: 48994@debbugs.gnu.org, mjbauer95@gmail.com, akrl@sdf.org Received: via spool by 48994-submit@debbugs.gnu.org id=B48994.162386916732573 (code B ref 48994); Wed, 16 Jun 2021 18:47:02 +0000 Received: (at 48994) by debbugs.gnu.org; 16 Jun 2021 18:46:07 +0000 Received: from localhost ([127.0.0.1]:53343 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ltaYB-0008So-B4 for submit@debbugs.gnu.org; Wed, 16 Jun 2021 14:46:07 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46378) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ltaY7-0008Kp-Pk for 48994@debbugs.gnu.org; Wed, 16 Jun 2021 14:46:05 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56636) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ltaY1-0006Ec-6g; Wed, 16 Jun 2021 14:45:57 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1031 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ltaXv-0000mw-MB; Wed, 16 Jun 2021 14:45:57 -0400 Date: Wed, 16 Jun 2021 21:45:50 +0300 Message-Id: <83fsxh1wdd.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Alan Third on Wed, 16 Jun 2021 19:25:14 +0100) References: <83y2be6zj8.fsf@gnu.org> <83bl897kag.fsf@gnu.org> <8335tk7h32.fsf@gnu.org> <835yyg5k4p.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 16 Jun 2021 19:25:14 +0100 > From: Alan Third > Cc: 48994@debbugs.gnu.org, mjbauer95@gmail.com, akrl@sdf.org > > > My primary worry is not the Makefiles, it's what the installed Emacs > > does upon startup to find its requisite files. > > I've done a lot of digging about and it looks like a bit of a mess, > frankly. It could be. But let me first ask you: did you understand how Emacs finds the directory with the *.eln files, and how that is related to finding the .pdmp file? These two parts are looked for together, and the place where we find the .pdmp file tells us directly where to look for the *.eln files. If this is "messy" on macOS, in either of the two types of install, then we should fix that first. >From what you describe, it sounds like not everything is well in that department: > configure hard-codes "lispdirrel" to Contents/Resources/lisp, which is > obviously wrong on a Unix style install, but is only "correct" on a > bundled app install because argv0 is set to the root of the app bundle > instead of the actual executable. > > I don't know why argv0 is set that way, but it must be how NS apps > work because I haven't yet seen any code changing it yet. > > The other place that's causing trouble is this wee bit in emacs.c: > > /* Assume the Emacs binary lives in a sibling directory as set up by > the default installation configuration. */ > const char *go_up = "../../../../bin/"; > > Which I assume works correctly in a Unix style install but doesn't > work in an app bundle install. So we need to make NS-specific changes that will make this work correctly both in Unix-style and the app bundle style install. Do you understand how to fix this part? I'll gladly help you if needed. > I'm feeling that perhaps we should expose the ns_self_contained > variable from configure/makefile to the C code so we can do different > things in a couple of places depending on what type of install we're > using. Trying to use the same code for both seems rather more > difficult than it needs to be. If the decision on the type of the install is at configure time, then we can have compile-time conditions in the source, yes. > > If the pdumper file is near the binary, I think Emacs will decide it's > > running uninstalled, and will look for the *.eln files in > > ../native-lisp relative to where the binary lives. Which is not > > necessarily what you want, AFAIU. > > That's easy enough to change. If I put it in the libexec directory it > works just as well. Then let's do that. In general, as much similarity between the two cases as is feasible is better, because it will make the code less messy, and will require us to remember fewer special cases. > > . Emacs binary in /usr/bin > > . the .pdmp file in /usr/libexec/emacs/VERSION/ARCHITECTURE > > . the *eln files in /usr/lib/emacs/VERSION/native-lisp > > > > ? > > Sorry, I must've missed it. > > Yes, a normal Unix style install should be like that. OK, then the Unix style install should already be working. Then I wonder how come this very install caused the OP trouble. But we can revisit it later, once the code whch looks for .pdmp and *.eln files is finalized. > However the OP appears to be using a Unix style install with a > different install prefix and is getting app bundle install paths in > his errors, specifically Contents/Resources/lisp, which I mentioned at > the top of the email. I wonder how this could happen, if the Unix style install is supposed to "just work". > > > I believe there's a ./configure flag. But like I said before, for the > > > other paths there's a run-time check, so I'm not sure how it all ties > > > together. > > > > Which run-time check did you have in mind? > > ns_exec_path, and friends. They return the app bundle paths if the > directories exist, and nil otherwise, then the code that calls them > modifies the search paths depending on the result. It's okay to use that, although I'd expect the install location to be known at compile time? > I think I can probably fix this now, hopefully without breaking > anything... ;) Fine, please do, but let's try doing that one step at a time... Thanks. From unknown Sun Jun 22 04:29:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS) Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Jun 2021 17:05:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48994 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: 48994@debbugs.gnu.org, mjbauer95@gmail.com, akrl@sdf.org Received: via spool by 48994-submit@debbugs.gnu.org id=B48994.16241222769352 (code B ref 48994); Sat, 19 Jun 2021 17:05:03 +0000 Received: (at 48994) by debbugs.gnu.org; 19 Jun 2021 17:04:36 +0000 Received: from localhost ([127.0.0.1]:60665 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lueOW-0002Qi-Jx for submit@debbugs.gnu.org; Sat, 19 Jun 2021 13:04:35 -0400 Received: from outbound.soverin.net ([116.202.126.228]:51543) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lueOS-0002QF-2P for 48994@debbugs.gnu.org; Sat, 19 Jun 2021 13:04:31 -0400 Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id BBCB9860; Sat, 19 Jun 2021 17:04:21 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1624122260; bh=jQw3HQBq26VzJM5avEW5JwA11uxFSL5+POYzoSWk7OM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=h1IgsjsbBo4p38HVleZf7wUr5UAky9Zyyyi/cFPH4Z2JyqbQ510Gx8zNkwDcUiKzA ApL2o84B1I/pk9bRcGCcA216prIdeGVqW9LP1d9rNhr7TbgLtMGkK+LXZqHdNyGvVy AcV7HjVUwt4KW+ovoInAL8QMOw2RXrpQ0ialiAK1WZsuQfWXhtspqHlkn4ycx58OTp PTSDM10aYxwSlKDmAWCpFnT9Y+U8aDl+h4vLyTm2BomZlb1ndDY3SrrEq/Ef5Fl0+G 72ZNlOfvFAMqPwyiq9pH6DU2Lk1tagjJXxJJJx1qIVSYSOv7wL2BvyAn+a2fI3qmYf 94cjw8YZlQsDQ== Received: from alan by faroe.holly.idiocy.org with local (Exim 4.94.2) (envelope-from ) id 1lueOI-0006An-1i; Sat, 19 Jun 2021 18:04:18 +0100 Date: Sat, 19 Jun 2021 18:04:18 +0100 From: Alan Third Message-ID: Mail-Followup-To: Alan Third , Eli Zaretskii , 48994@debbugs.gnu.org, mjbauer95@gmail.com, akrl@sdf.org References: <83y2be6zj8.fsf@gnu.org> <83bl897kag.fsf@gnu.org> <8335tk7h32.fsf@gnu.org> <835yyg5k4p.fsf@gnu.org> <83fsxh1wdd.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="m4rjHJYXPTKwY5xl" Content-Disposition: inline In-Reply-To: <83fsxh1wdd.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --m4rjHJYXPTKwY5xl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jun 16, 2021 at 09:45:50PM +0300, Eli Zaretskii wrote: > > Date: Wed, 16 Jun 2021 19:25:14 +0100 > > From: Alan Third > > Cc: 48994@debbugs.gnu.org, mjbauer95@gmail.com, akrl@sdf.org > > > > > My primary worry is not the Makefiles, it's what the installed Emacs > > > does upon startup to find its requisite files. > > > > I've done a lot of digging about and it looks like a bit of a mess, > > frankly. > > It could be. But let me first ask you: did you understand how Emacs > finds the directory with the *.eln files, and how that is related to > finding the .pdmp file? These two parts are looked for together, and > the place where we find the .pdmp file tells us directly where to look > for the *.eln files. > > If this is "messy" on macOS, in either of the two types of install, > then we should fix that first. I think I did understand that. As far as I can tell that bit actually works fine, as long as the pdmp file can be found the eln files can be found. > So we need to make NS-specific changes that will make this work > correctly both in Unix-style and the app bundle style install. Do you > understand how to fix this part? I'll gladly help you if needed. I've attached a patch which, I hope, should solve these problems. I've tried to align the code more with how other terms work, so I've removed all the functions that calculate the various paths Emacs uses, and replaced them with a single function that, given a relative path inside the application bundle, can work out what the full path should be, but will pass any absolute paths unchanged. It's similar to w32_relocate, but not exactly the same, and I'm using it in more places due to the app bundle layout being quite different. I've also followed the w32 lead in changing how epaths.h is generated. Basically I post-process it so that any paths that are internal to the app bundle are converted to relative paths, so the above mentioned function can deal with them. > > > . Emacs binary in /usr/bin > > > . the .pdmp file in /usr/libexec/emacs/VERSION/ARCHITECTURE > > > . the *eln files in /usr/lib/emacs/VERSION/native-lisp > > > > > > ? > > > > Sorry, I must've missed it. > > > > Yes, a normal Unix style install should be like that. > > OK, then the Unix style install should already be working. Then I > wonder how come this very install caused the OP trouble. But we can > revisit it later, once the code whch looks for .pdmp and *.eln files > is finalized. > > > However the OP appears to be using a Unix style install with a > > different install prefix and is getting app bundle install paths in > > his errors, specifically Contents/Resources/lisp, which I mentioned at > > the top of the email. > > I wonder how this could happen, if the Unix style install is supposed > to "just work". I think it's because of some hard-coding of things that was added to work around problems in the app bundle code. They haven't been suitably separated from the Unix style install code, so they end up interfering with each other. I think that now a Unix style install shouldn't be affected at all by the app bundle code, but I'd like some extra testing by people who run it that way before I'm fully convinced I've been successful in that. > > > > I believe there's a ./configure flag. But like I said before, for the > > > > other paths there's a run-time check, so I'm not sure how it all ties > > > > together. > > > > > > Which run-time check did you have in mind? > > > > ns_exec_path, and friends. They return the app bundle paths if the > > directories exist, and nil otherwise, then the code that calls them > > modifies the search paths depending on the result. > > It's okay to use that, although I'd expect the install location to be > known at compile time? The install location is known, but in the app bundle case the app can be copied to anywhere and then the full paths will be different, so they can't just be hard coded at install time. > > I think I can probably fix this now, hopefully without breaking > > anything... ;) > > Fine, please do, but let's try doing that one step at a time... I tried, but it ended up quite a large patch as fixing one thing would invariably break another, and I decided I had to sort out the epaths.h situation before I could do much else, and most of the rest of the patch is dealing with the fallout from that. Anyway, it's attached. It's working here for the app bundle case and I believe it should work well for the Unix style install, but I've not tested that in any depth. Matthew, could you please try the attached patch and see if it solves your problems (or makes them worse!)? -- Alan Third --m4rjHJYXPTKwY5xl Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0001-Fix-NS-native-compilation-builds.patch" >From ec5a25237cbee92d110e2226eb4f70d781d535c8 Mon Sep 17 00:00:00 2001 From: Alan Third Date: Wed, 16 Jun 2021 21:28:10 +0100 Subject: [PATCH] Fix NS native compilation builds * Makefile.in (ns_appdir): New variable. (.PHONY): Include new rule. (epaths-force-ns-self-contained): Remove the app bundle directory from all paths. * configure.ac (NS_SELF_CONTAINED): Set the default site-lisp directory instead of hard-coding it in the ObjC code, and use the new epaths generating make rule. * src/callproc.c (init_callproc_1): (init_callproc): Remove all the NS specific code as the special cases are now handled by decode_env_path. * src/emacs.c (load_pdump): (decode_env_path): Use ns_relocate to find the correct directory after relocation. * src/lread.c (load_path_default): Remove all the NS specific code as the special cases are now handled by decode_env_path. * src/nsterm.h: Update function definitions. * src/nsterm.m (ns_etc_directory): (ns_exec_path): (ns_load_path): Remove functions that are no longer needed. (ns_relocate): New function to calculate paths within the NS app bundle. --- Makefile.in | 17 +++++- configure.ac | 12 +++-- nextstep/Makefile.in | 10 ++-- src/callproc.c | 36 ++----------- src/emacs.c | 16 +++++- src/lread.c | 7 +-- src/nsterm.h | 4 +- src/nsterm.m | 125 ++++++++----------------------------------- 8 files changed, 71 insertions(+), 156 deletions(-) diff --git a/Makefile.in b/Makefile.in index 3facfa59a9..68fe7d781a 100644 --- a/Makefile.in +++ b/Makefile.in @@ -104,8 +104,10 @@ HAVE_NATIVE_COMP = # Location to install Emacs.app under GNUstep / macOS. # Later values may use these. +ns_appdir=@ns_appdir@ ns_appbindir=@ns_appbindir@ ns_appresdir=@ns_appresdir@ +ns_applibdir=@ns_applibdir@ # Either yes or no depending on whether this is a relocatable Emacs.app. ns_self_contained=@ns_self_contained@ @@ -328,12 +330,12 @@ BIN_DESTDIR= ELN_DESTDIR = $(DESTDIR)${libdir}/emacs/${version}/ else BIN_DESTDIR='${ns_appbindir}/' -ELN_DESTDIR = ${ns_appresdir}/ +ELN_DESTDIR = ${ns_applibdir}/emacs/${version}/ endif all: ${SUBDIR} info -.PHONY: all ${SUBDIR} blessmail epaths-force epaths-force-w32 etc-emacsver +.PHONY: all ${SUBDIR} blessmail epaths-force epaths-force-w32 epaths-force-ns-self-contained etc-emacsver # If configure were to just generate emacsver.tex from emacsver.tex.in # in the normal way, the timestamp of emacsver.tex would always be @@ -402,6 +404,17 @@ epaths-force-w32: -e "/^.*#/s|@SRC@|$${w32srcdir}|g") && \ ${srcdir}/build-aux/move-if-change epaths.h.$$$$ src/epaths.h +# A NextStep style app bundle is relocatable, so instead of +# hard-coding paths try to generate them at run-time. +# +# The paths are mostly the same, and the bundle paths are different +# between macOS and GNUstep, so just replace any references to the app +# bundle root itself with the relative path. +epaths-force-ns-self-contained: epaths-force + @(sed < ${srcdir}/src/epaths.h > epaths.h.$$$$ \ + -e 's;${ns_appdir}/;;') && \ + ${srcdir}/build-aux/move-if-change epaths.h.$$$$ src/epaths.h + lib-src src: $(NTDIR) lib src: lib-src diff --git a/configure.ac b/configure.ac index c828f8d782..05afdbc8b8 100644 --- a/configure.ac +++ b/configure.ac @@ -1891,10 +1891,10 @@ AC_DEFUN # so avoid NS_IMPL_COCOA if macuvs.h is absent. # Even a headless Emacs can build macuvs.h, so this should let you bootstrap. if test "${opsys}" = darwin && test -f "$srcdir/src/macuvs.h"; then - lispdirrel=Contents/Resources/lisp NS_IMPL_COCOA=yes ns_appdir=`pwd`/nextstep/Emacs.app ns_appbindir=${ns_appdir}/Contents/MacOS + ns_applibdir=${ns_appdir}/Contents/MacOS/lib ns_appresdir=${ns_appdir}/Contents/Resources ns_appsrc=Cocoa/Emacs.base ns_fontfile=macfont.o @@ -1952,6 +1952,7 @@ AC_DEFUN if test $NS_IMPL_GNUSTEP = yes; then ns_appdir=`pwd`/nextstep/Emacs.app ns_appbindir=${ns_appdir} + ns_applibdir=${ns_appdir}/lib ns_appresdir=${ns_appdir}/Resources ns_appsrc=GNUstep/Emacs.base ns_fontfile=nsfont.o @@ -2008,6 +2009,7 @@ AC_DEFUN window_system=nextstep # set up packaging dirs if test "${EN_NS_SELF_CONTAINED}" = yes; then + AC_DEFINE(NS_SELF_CONTAINED, 1, [Build an NS bundled app]) ns_self_contained=yes prefix=${ns_appresdir} exec_prefix=${ns_appbindir} @@ -2021,7 +2023,7 @@ AC_DEFUN infodir="\${ns_appresdir}/info" mandir="\${ns_appresdir}/man" lispdir="\${ns_appresdir}/lisp" - test "$locallisppathset" = no && locallisppath="" + test "$locallisppathset" = no && locallisppath="\${ns_appresdir}/site-lisp" INSTALL_ARCH_INDEP_EXTRA= fi @@ -5409,6 +5411,7 @@ AC_DEFUN AC_SUBST(X_TOOLKIT_TYPE) AC_SUBST(ns_appdir) AC_SUBST(ns_appbindir) +AC_SUBST(ns_applibdir) AC_SUBST(ns_appresdir) AC_SUBST(ns_appsrc) AC_SUBST(GNU_OBJC_CFLAGS) @@ -6009,10 +6012,13 @@ m4_define AC_CONFIG_COMMANDS([src/epaths.h], [ if test "${opsys}" = "mingw32"; then ${MAKE-make} MAKEFILE_NAME=do-not-make-Makefile epaths-force-w32 +elif test "$EN_NS_SELF_CONTAINED" = "yes"; then + ${MAKE-make} MAKEFILE_NAME=do-not-make-Makefile epaths-force-ns-self-contained else ${MAKE-make} MAKEFILE_NAME=do-not-make-Makefile epaths-force fi || AC_MSG_ERROR(['src/epaths.h' could not be made.]) -], [GCC="$GCC" CPPFLAGS="$CPPFLAGS" opsys="$opsys"]) +], [GCC="$GCC" CPPFLAGS="$CPPFLAGS" opsys="$opsys" + EN_NS_SELF_CONTAINED="$EN_NS_SELF_CONTAINED"]) dnl NB we have to cheat and use the ac_... version because abs_top_srcdir dnl is not yet set, sigh. Or we could use ../$srcdir/src/.gdbinit, diff --git a/nextstep/Makefile.in b/nextstep/Makefile.in index 3168fee76c..c0beb454d1 100644 --- a/nextstep/Makefile.in +++ b/nextstep/Makefile.in @@ -38,13 +38,14 @@ ns_appdir = ns_appbindir = @ns_appbindir@ ## GNUstep/Emacs.base or Cocoa/Emacs.base. ns_appsrc = @ns_appsrc@ +ns_applibexecdir = @libexecdir@ ## GNUstep: GNUstep/Emacs.base/Resources/Info-gnustep.plist ## macOS: Cocoa/Emacs.base/Contents/Info.plist ns_check_file = @ns_appdir@/@ns_check_file@ .PHONY: all -all: ${ns_appdir} ${ns_appbindir}/Emacs ${ns_appbindir}/Emacs.pdmp +all: ${ns_appdir} ${ns_appbindir}/Emacs ${ns_applibexecdir}/Emacs.pdmp ${ns_check_file} ${ns_appdir}: ${srcdir}/${ns_appsrc} ${ns_appsrc} rm -rf ${ns_appdir} @@ -63,8 +64,8 @@ ${ns_appbindir}/Emacs: ${MKDIR_P} ${ns_appbindir} cp -f ../src/emacs${EXEEXT} $@ -${ns_appbindir}/Emacs.pdmp: ${ns_appdir} ${ns_check_file} ../src/emacs${EXEEXT}.pdmp - ${MKDIR_P} ${ns_appbindir} +${ns_applibexecdir}/Emacs.pdmp: ${ns_appdir} ${ns_check_file} ../src/emacs${EXEEXT}.pdmp + ${MKDIR_P} ${ns_applibexecdir} cp -f ../src/emacs${EXEEXT}.pdmp $@ .PHONY: FORCE @@ -85,9 +86,8 @@ links: ln -s $(top_srcdir_abs)/info ${ns_appdir}/Contents/Resources ${MKDIR_P} ${ns_appbindir} ln -s $(abs_top_builddir)/src/emacs${EXEEXT} ${ns_appbindir}/Emacs - ln -s $(abs_top_builddir)/src/emacs${EXEEXT}.pdmp ${ns_appbindir}/Emacs.pdmp ln -s $(abs_top_builddir)/lib-src ${ns_appbindir}/bin - ln -s $(abs_top_builddir)/lib-src ${ns_appbindir}/libexec + ln -s $(abs_top_builddir)/lib-src ${ns_applibexecdir} ${MKDIR_P} ${ns_appdir}/Contents/Resources/etc for f in $(shell cd $(top_srcdir_abs)/etc; ls); do ln -s $(top_srcdir_abs)/etc/$$f ${ns_appdir}/Contents/Resources/etc; done ln -s $(abs_top_builddir)/etc/DOC ${ns_appdir}/Contents/Resources/etc diff --git a/src/callproc.c b/src/callproc.c index e44e243680..aabc39313b 100644 --- a/src/callproc.c +++ b/src/callproc.c @@ -1661,32 +1661,15 @@ make_environment_block (Lisp_Object current_dir) void init_callproc_1 (void) { -#ifdef HAVE_NS - const char *etc_dir = ns_etc_directory (); - const char *path_exec = ns_exec_path (); -#endif - - Vdata_directory = decode_env_path ("EMACSDATA", -#ifdef HAVE_NS - etc_dir ? etc_dir : -#endif - PATH_DATA, 0); + Vdata_directory = decode_env_path ("EMACSDATA", PATH_DATA, 0); Vdata_directory = Ffile_name_as_directory (Fcar (Vdata_directory)); - Vdoc_directory = decode_env_path ("EMACSDOC", -#ifdef HAVE_NS - etc_dir ? etc_dir : -#endif - PATH_DOC, 0); + Vdoc_directory = decode_env_path ("EMACSDOC", PATH_DOC, 0); Vdoc_directory = Ffile_name_as_directory (Fcar (Vdoc_directory)); /* Check the EMACSPATH environment variable, defaulting to the PATH_EXEC path from epaths.h. */ - Vexec_path = decode_env_path ("EMACSPATH", -#ifdef HAVE_NS - path_exec ? path_exec : -#endif - PATH_EXEC, 0); + Vexec_path = decode_env_path ("EMACSPATH", PATH_EXEC, 0); Vexec_directory = Ffile_name_as_directory (Fcar (Vexec_path)); /* FIXME? For ns, path_exec should go at the front? */ Vexec_path = nconc2 (decode_env_path ("PATH", "", 0), Vexec_path); @@ -1701,10 +1684,6 @@ init_callproc (void) char *sh; Lisp_Object tempdir; -#ifdef HAVE_NS - if (data_dir == 0) - data_dir = ns_etc_directory () != 0; -#endif if (!NILP (Vinstallation_directory)) { @@ -1716,15 +1695,8 @@ init_callproc (void) /* MSDOS uses wrapped binaries, so don't do this. */ if (NILP (Fmember (tem, Vexec_path))) { -#ifdef HAVE_NS - const char *path_exec = ns_exec_path (); -#endif /* Running uninstalled, so default to tem rather than PATH_EXEC. */ - Vexec_path = decode_env_path ("EMACSPATH", -#ifdef HAVE_NS - path_exec ? path_exec : -#endif - SSDATA (tem), 0); + Vexec_path = decode_env_path ("EMACSPATH", SSDATA (tem), 0); Vexec_path = nconc2 (decode_env_path ("PATH", "", 0), Vexec_path); } diff --git a/src/emacs.c b/src/emacs.c index 60a57a693c..b7982ece64 100644 --- a/src/emacs.c +++ b/src/emacs.c @@ -835,7 +835,13 @@ load_pdump (int argc, char **argv) NULL #endif ; - const char *argv0_base = "emacs"; + const char *argv0_base = +#ifdef NS_SELF_CONTAINED + "Emacs" +#else + "emacs" +#endif + ; /* TODO: maybe more thoroughly scrub process environment in order to make this use case (loading a dump file in an unexeced emacs) @@ -912,6 +918,8 @@ load_pdump (int argc, char **argv) /* On MS-Windows, PATH_EXEC normally starts with a literal "%emacs_dir%", so it will never work without some tweaking. */ path_exec = w32_relocate (path_exec); +#elif defined (HAVE_NS) + path_exec = ns_relocate (path_exec); #endif /* Look for "emacs.pdmp" in PATH_EXEC. We hardcode "emacs" in @@ -929,6 +937,7 @@ load_pdump (int argc, char **argv) } sprintf (dump_file, "%s%c%s%s", path_exec, DIRECTORY_SEP, argv0_base, suffix); +#if !defined (NS_SELF_CONTAINED) /* Assume the Emacs binary lives in a sibling directory as set up by the default installation configuration. */ const char *go_up = "../../../../bin/"; @@ -943,6 +952,7 @@ load_pdump (int argc, char **argv) sprintf (emacs_executable, "%s%c%s%s%s", path_exec, DIRECTORY_SEP, go_up, argv0_base, strip_suffix ? strip_suffix : ""); +#endif result = pdumper_load (dump_file, emacs_executable); if (result == PDUMPER_LOAD_FILE_NOT_FOUND) @@ -2960,7 +2970,11 @@ decode_env_path (const char *evarname, const char *defalt, bool empty) path = 0; if (!path) { +#ifdef NS_SELF_CONTAINED + path = ns_relocate (defalt); +#else path = defalt; +#endif #ifdef WINDOWSNT defaulted = 1; #endif diff --git a/src/lread.c b/src/lread.c index 0b33fd0f25..4617ffd626 100644 --- a/src/lread.c +++ b/src/lread.c @@ -4769,14 +4769,9 @@ load_path_default (void) return decode_env_path (0, PATH_DUMPLOADSEARCH, 0); Lisp_Object lpath = Qnil; - const char *normal = PATH_LOADSEARCH; const char *loadpath = NULL; -#ifdef HAVE_NS - loadpath = ns_load_path (); -#endif - - lpath = decode_env_path (0, loadpath ? loadpath : normal, 0); + lpath = decode_env_path (0, PATH_LOADSEARCH, 0); if (!NILP (Vinstallation_directory)) { diff --git a/src/nsterm.h b/src/nsterm.h index e7ea907569..139c37a29e 100644 --- a/src/nsterm.h +++ b/src/nsterm.h @@ -1186,9 +1186,7 @@ #define NSAPP_DATA2_RUNASSCRIPT 10 #define NSAPP_DATA2_RUNFILEDIALOG 11 extern void ns_run_file_dialog (void); -extern const char *ns_etc_directory (void); -extern const char *ns_exec_path (void); -extern const char *ns_load_path (void); +extern const char *ns_relocate (const char *epath); extern void syms_of_nsterm (void); extern void syms_of_nsfns (void); extern void syms_of_nsmenu (void); diff --git a/src/nsterm.m b/src/nsterm.m index 838c14d5ab..7b0b169e10 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -499,118 +499,35 @@ - (NSColor *)colorUsingDefaultColorSpace const char * -ns_etc_directory (void) -/* If running as a self-contained app bundle, return as a string the - filename of the etc directory, if present; else nil. */ -{ - NSBundle *bundle = [NSBundle mainBundle]; - NSString *resourceDir = [bundle resourcePath]; - NSString *resourcePath; - NSFileManager *fileManager = [NSFileManager defaultManager]; - BOOL isDir; +ns_relocate (const char *epath) +/* If we're running in a self-contained app bundle some hard-coded + paths are relative to the root of the bundle, so work out the full + path. - resourcePath = [resourceDir stringByAppendingPathComponent: @"etc"]; - if ([fileManager fileExistsAtPath: resourcePath isDirectory: &isDir]) - { - if (isDir) return [resourcePath UTF8String]; - } - return NULL; -} - - -const char * -ns_exec_path (void) -/* If running as a self-contained app bundle, return as a path string - the filenames of the libexec and bin directories, ie libexec:bin. - Otherwise, return nil. - Normally, Emacs does not add its own bin/ directory to the PATH. - However, a self-contained NS build has a different layout, with - bin/ and libexec/ subdirectories in the directory that contains - Emacs.app itself. - We put libexec first, because init_callproc_1 uses the first - element to initialize exec-directory. An alternative would be - for init_callproc to check for invocation-directory/libexec. -*/ + FIXME: I think this should be able to handle cases where multiple + directories are separated by colons. */ { +#ifdef NS_SELF_CONTAINED NSBundle *bundle = [NSBundle mainBundle]; - NSString *resourceDir = [bundle resourcePath]; - NSString *binDir = [bundle bundlePath]; - NSString *resourcePath, *resourcePaths; - NSRange range; - NSString *pathSeparator = [NSString stringWithFormat: @"%c", SEPCHAR]; + NSString *root = [bundle bundlePath]; + NSString *original = [NSString stringWithUTF8String:epath]; + NSString *fixedPath = [NSString pathWithComponents:@[root, original]]; NSFileManager *fileManager = [NSFileManager defaultManager]; - NSArray *paths; - NSEnumerator *pathEnum; - BOOL isDir; - range = [resourceDir rangeOfString: @"Contents"]; - if (range.location != NSNotFound) - { - binDir = [binDir stringByAppendingPathComponent: @"Contents"]; -#ifdef NS_IMPL_COCOA - binDir = [binDir stringByAppendingPathComponent: @"MacOS"]; -#endif - } + if (![original isAbsolutePath] + && [fileManager fileExistsAtPath:fixedPath isDirectory:nil]) + return [fixedPath UTF8String]; - paths = [binDir stringsByAppendingPaths: - [NSArray arrayWithObjects: @"libexec", @"bin", nil]]; - pathEnum = [paths objectEnumerator]; - resourcePaths = @""; + /* If we reach here either the path is absolute and therefore we + don't need to complete it, or we're unable to relocate the + file/directory. If it's the latter it may be because the user is + trying to use a bundled app as though it's a Unix style install + and we have no way to guess what was intended, so return the + original string unaltered. */ - while ((resourcePath = [pathEnum nextObject])) - { - if ([fileManager fileExistsAtPath: resourcePath isDirectory: &isDir]) - if (isDir) - { - if ([resourcePaths length] > 0) - resourcePaths - = [resourcePaths stringByAppendingString: pathSeparator]; - resourcePaths - = [resourcePaths stringByAppendingString: resourcePath]; - } - } - if ([resourcePaths length] > 0) return [resourcePaths UTF8String]; - - return NULL; -} - - -const char * -ns_load_path (void) -/* If running as a self-contained app bundle, return as a path string - the filenames of the site-lisp and lisp directories. - Ie, site-lisp:lisp. Otherwise, return nil. */ -{ - NSBundle *bundle = [NSBundle mainBundle]; - NSString *resourceDir = [bundle resourcePath]; - NSString *resourcePath, *resourcePaths; - NSString *pathSeparator = [NSString stringWithFormat: @"%c", SEPCHAR]; - NSFileManager *fileManager = [NSFileManager defaultManager]; - BOOL isDir; - NSArray *paths = [resourceDir stringsByAppendingPaths: - [NSArray arrayWithObjects: - @"site-lisp", @"lisp", nil]]; - NSEnumerator *pathEnum = [paths objectEnumerator]; - resourcePaths = @""; - - /* Hack to skip site-lisp. */ - if (no_site_lisp) resourcePath = [pathEnum nextObject]; - - while ((resourcePath = [pathEnum nextObject])) - { - if ([fileManager fileExistsAtPath: resourcePath isDirectory: &isDir]) - if (isDir) - { - if ([resourcePaths length] > 0) - resourcePaths - = [resourcePaths stringByAppendingString: pathSeparator]; - resourcePaths - = [resourcePaths stringByAppendingString: resourcePath]; - } - } - if ([resourcePaths length] > 0) return [resourcePaths UTF8String]; +#endif - return NULL; + return epath; } -- 2.30.2 --m4rjHJYXPTKwY5xl-- From unknown Sun Jun 22 04:29:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS) Resent-From: Matthew Bauer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 Jun 2021 03:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48994 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Alan Third , Eli Zaretskii , 48994@debbugs.gnu.org, Matthew Bauer , Andrea Corallo Received: via spool by 48994-submit@debbugs.gnu.org id=B48994.162433416022126 (code B ref 48994); Tue, 22 Jun 2021 03:56:01 +0000 Received: (at 48994) by debbugs.gnu.org; 22 Jun 2021 03:56:00 +0000 Received: from localhost ([127.0.0.1]:37212 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lvXW3-0005kn-Mf for submit@debbugs.gnu.org; Mon, 21 Jun 2021 23:56:00 -0400 Received: from mail-ej1-f44.google.com ([209.85.218.44]:36714) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lvXW1-0005ka-P3 for 48994@debbugs.gnu.org; Mon, 21 Jun 2021 23:55:58 -0400 Received: by mail-ej1-f44.google.com with SMTP id nd37so32251116ejc.3 for <48994@debbugs.gnu.org>; Mon, 21 Jun 2021 20:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zbaIM5Pm6gQghQZfINxZj91wsN7rrA1HPRD1ywPi3Qg=; b=oDkKwlFJFo18voVi+lPUv9omo2kR5jg+r8c56yx3C2rAUEVroCyQ9PNUM2FCsUyViL yPYaHfE3HILnQj1dCQ8raqa2zyRlvNoWf5y0AAkAyzCvYoPVS5ZGOk2bTYSAjdD5THOp sRpMhef0MbCL4UHifJwgDwnuXkPgGCCc8NvEQZ41XjLAzshSKGK4KT3M71oHyue5lc/f dBNd4heQ3ngiMgaXlvhVvS1hnQXV3JYmHAfk2fiD9iSxBpcjbtRb9RrNp8tW8sx/ygfn 16b13byXbSGXpMP0i/LXiXnfH/FIgi/9a0JZ3S9lHkajbur04nn8h3uBAKn1Yx2wzWkC E+wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=zbaIM5Pm6gQghQZfINxZj91wsN7rrA1HPRD1ywPi3Qg=; b=HMsV0748wXfUPjkXac1Xyns0nIFJhB9vBHdUm5jzUwAErdS6qXncilWAhavzmmWEfg eCdwRwiwOq5FLgyOosHhkwYRIvKRp7JefIK6ksXrPKOTC+g9zkPmFllesLyQ9XcQFb0l WL/1rYLME1asVUH2fQvSAx8bKmgmeAiQjgOyFWGQ4hpBkbP6v6Zejn9wWaRk2a/v8B04 gQF327BR6z9YfvKCiX3KiwNigB2ijnmzzCEvBf5Rhl/0+zYPQhwBvBJeInYS4FsEH2LD WanTN2Jb+LpLEDvCEy1+PCgDs/6NW4odDh2kaYxuQTrgBo0HFSiYKntMWhLTH0Vx8uF7 EMLQ== X-Gm-Message-State: AOAM533CIH6CBYLqjLme2HugmDKEz3oBcb1TC7/J0ZIldht75ov3LsMz s3bve8SYo6zussZBWkM6aJR0SONECsG3e2xtPOQ= X-Google-Smtp-Source: ABdhPJz57f0rWp3oPLPrx65x54MtmXotELsSkseKo1c8ANKnLrEUnGDb3GiPtj2EP4dTmvDweOH3F94l2iJbdx3iTw0= X-Received: by 2002:a17:906:2a8e:: with SMTP id l14mr1556461eje.549.1624334151632; Mon, 21 Jun 2021 20:55:51 -0700 (PDT) MIME-Version: 1.0 References: <83y2be6zj8.fsf@gnu.org> <83bl897kag.fsf@gnu.org> <8335tk7h32.fsf@gnu.org> <835yyg5k4p.fsf@gnu.org> <83fsxh1wdd.fsf@gnu.org> In-Reply-To: From: Matthew Bauer Date: Mon, 21 Jun 2021 22:55:40 -0500 Message-ID: Content-Type: multipart/mixed; boundary="0000000000001ae9a905c552c4c8" X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --0000000000001ae9a905c552c4c8 Content-Type: multipart/alternative; boundary="0000000000001ae9a805c552c4c6" --0000000000001ae9a805c552c4c6 Content-Type: text/plain; charset="UTF-8" > Matthew, could you please try the attached patch and see if it solves > your problems (or makes them worse!)? That fixes the problem! I had to make a small change for it to work though (needed to add prefix & exec_prefix to nextstep/Makefile.in). On Sat, Jun 19, 2021 at 12:04 PM Alan Third wrote: > On Wed, Jun 16, 2021 at 09:45:50PM +0300, Eli Zaretskii wrote: > > > Date: Wed, 16 Jun 2021 19:25:14 +0100 > > > From: Alan Third > > > Cc: 48994@debbugs.gnu.org, mjbauer95@gmail.com, akrl@sdf.org > > > > > > > My primary worry is not the Makefiles, it's what the installed Emacs > > > > does upon startup to find its requisite files. > > > > > > I've done a lot of digging about and it looks like a bit of a mess, > > > frankly. > > > > It could be. But let me first ask you: did you understand how Emacs > > finds the directory with the *.eln files, and how that is related to > > finding the .pdmp file? These two parts are looked for together, and > > the place where we find the .pdmp file tells us directly where to look > > for the *.eln files. > > > > If this is "messy" on macOS, in either of the two types of install, > > then we should fix that first. > > I think I did understand that. As far as I can tell that bit actually > works fine, as long as the pdmp file can be found the eln files can be > found. > > > So we need to make NS-specific changes that will make this work > > correctly both in Unix-style and the app bundle style install. Do you > > understand how to fix this part? I'll gladly help you if needed. > > I've attached a patch which, I hope, should solve these problems. I've > tried to align the code more with how other terms work, so I've > removed all the functions that calculate the various paths Emacs uses, > and replaced them with a single function that, given a relative path > inside the application bundle, can work out what the full path should > be, but will pass any absolute paths unchanged. > > It's similar to w32_relocate, but not exactly the same, and I'm using > it in more places due to the app bundle layout being quite different. > > I've also followed the w32 lead in changing how epaths.h is generated. > Basically I post-process it so that any paths that are internal to the > app bundle are converted to relative paths, so the above mentioned > function can deal with them. > > > > > . Emacs binary in /usr/bin > > > > . the .pdmp file in /usr/libexec/emacs/VERSION/ARCHITECTURE > > > > . the *eln files in /usr/lib/emacs/VERSION/native-lisp > > > > > > > > ? > > > > > > Sorry, I must've missed it. > > > > > > Yes, a normal Unix style install should be like that. > > > > OK, then the Unix style install should already be working. Then I > > wonder how come this very install caused the OP trouble. But we can > > revisit it later, once the code whch looks for .pdmp and *.eln files > > is finalized. > > > > > However the OP appears to be using a Unix style install with a > > > different install prefix and is getting app bundle install paths in > > > his errors, specifically Contents/Resources/lisp, which I mentioned at > > > the top of the email. > > > > I wonder how this could happen, if the Unix style install is supposed > > to "just work". > > I think it's because of some hard-coding of things that was added to > work around problems in the app bundle code. They haven't been > suitably separated from the Unix style install code, so they end up > interfering with each other. > > I think that now a Unix style install shouldn't be affected at all by > the app bundle code, but I'd like some extra testing by people who run > it that way before I'm fully convinced I've been successful in that. > > > > > > I believe there's a ./configure flag. But like I said before, for > the > > > > > other paths there's a run-time check, so I'm not sure how it all > ties > > > > > together. > > > > > > > > Which run-time check did you have in mind? > > > > > > ns_exec_path, and friends. They return the app bundle paths if the > > > directories exist, and nil otherwise, then the code that calls them > > > modifies the search paths depending on the result. > > > > It's okay to use that, although I'd expect the install location to be > > known at compile time? > > The install location is known, but in the app bundle case the app can > be copied to anywhere and then the full paths will be different, so > they can't just be hard coded at install time. > > > > I think I can probably fix this now, hopefully without breaking > > > anything... ;) > > > > Fine, please do, but let's try doing that one step at a time... > > I tried, but it ended up quite a large patch as fixing one thing would > invariably break another, and I decided I had to sort out the epaths.h > situation before I could do much else, and most of the rest of the > patch is dealing with the fallout from that. > > Anyway, it's attached. It's working here for the app bundle case and I > believe it should work well for the Unix style install, but I've not > tested that in any depth. > > Matthew, could you please try the attached patch and see if it solves > your problems (or makes them worse!)? > -- > Alan Third > --0000000000001ae9a805c552c4c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0Matthew, could you please try the attached patch and se= e if it solves
> your problems (or makes them worse!)?

That fixes the problem! I had to make a small chang= e for it to work though (needed to add prefix &=C2=A0exec_prefix to=C2= =A0nextstep/Makefile.in).

On Sat, Jun 19, 2021 at 12= :04 PM Alan Third <alan@idiocy.org> wrote:
On Wed, Jun 16, 2021 at 09:45:50PM += 0300, Eli Zaretskii wrote:
> > Date: Wed, 16 Jun 2021 19:25:14 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: 48= 994@debbugs.gnu.org, mjbauer95@gmail.com, akrl@sdf.org
> >
> > > My primary worry is not the Makefiles, it's what the ins= talled Emacs
> > > does upon startup to find its requisite files.
> >
> > I've done a lot of digging about and it looks like a bit of a= mess,
> > frankly.
>
> It could be.=C2=A0 But let me first ask you: did you understand how Em= acs
> finds the directory with the *.eln files, and how that is related to > finding the .pdmp file?=C2=A0 These two parts are looked for together,= and
> the place where we find the .pdmp file tells us directly where to look=
> for the *.eln files.
>
> If this is "messy" on macOS, in either of the two types of i= nstall,
> then we should fix that first.

I think I did understand that. As far as I can tell that bit actually
works fine, as long as the pdmp file can be found the eln files can be
found.

> So we need to make NS-specific changes that will make this work
> correctly both in Unix-style and the app bundle style install.=C2=A0 D= o you
> understand how to fix this part?=C2=A0 I'll gladly help you if nee= ded.

I've attached a patch which, I hope, should solve these problems. I'= ;ve
tried to align the code more with how other terms work, so I've
removed all the functions that calculate the various paths Emacs uses,
and replaced them with a single function that, given a relative path
inside the application bundle, can work out what the full path should
be, but will pass any absolute paths unchanged.

It's similar to w32_relocate, but not exactly the same, and I'm usi= ng
it in more places due to the app bundle layout being quite different.

I've also followed the w32 lead in changing how epaths.h is generated.<= br> Basically I post-process it so that any paths that are internal to the
app bundle are converted to relative paths, so the above mentioned
function can deal with them.

> > >=C2=A0 =C2=A0. Emacs binary in /usr/bin
> > >=C2=A0 =C2=A0. the .pdmp file in /usr/libexec/emacs/VERSION/A= RCHITECTURE
> > >=C2=A0 =C2=A0. the *eln files in /usr/lib/emacs/VERSION/nativ= e-lisp
> > >
> > > ?
> >
> > Sorry, I must've missed it.
> >
> > Yes, a normal Unix style install should be like that.
>
> OK, then the Unix style install should already be working.=C2=A0 Then = I
> wonder how come this very install caused the OP trouble.=C2=A0 But we = can
> revisit it later, once the code whch looks for .pdmp and *.eln files > is finalized.
>
> > However the OP appears to be using a Unix style install with a > > different install prefix and is getting app bundle install paths = in
> > his errors, specifically Contents/Resources/lisp, which I mention= ed at
> > the top of the email.
>
> I wonder how this could happen, if the Unix style install is supposed<= br> > to "just work".

I think it's because of some hard-coding of things that was added to work around problems in the app bundle code. They haven't been
suitably separated from the Unix style install code, so they end up
interfering with each other.

I think that now a Unix style install shouldn't be affected at all by the app bundle code, but I'd like some extra testing by people who run<= br> it that way before I'm fully convinced I've been successful in that= .

> > > > I believe there's a ./configure flag. But like I sa= id before, for the
> > > > other paths there's a run-time check, so I'm no= t sure how it all ties
> > > > together.
> > >
> > > Which run-time check did you have in mind?
> >
> > ns_exec_path, and friends. They return the app bundle paths if th= e
> > directories exist, and nil otherwise, then the code that calls th= em
> > modifies the search paths depending on the result.
>
> It's okay to use that, although I'd expect the install locatio= n to be
> known at compile time?

The install location is known, but in the app bundle case the app can
be copied to anywhere and then the full paths will be different, so
they can't just be hard coded at install time.

> > I think I can probably fix this now, hopefully without breaking > > anything... ;)
>
> Fine, please do, but let's try doing that one step at a time...
I tried, but it ended up quite a large patch as fixing one thing would
invariably break another, and I decided I had to sort out the epaths.h
situation before I could do much else, and most of the rest of the
patch is dealing with the fallout from that.

Anyway, it's attached. It's working here for the app bundle case an= d I
believe it should work well for the Unix style install, but I've not tested that in any depth.

Matthew, could you please try the attached patch and see if it solves
your problems (or makes them worse!)?
--
Alan Third
--0000000000001ae9a805c552c4c6-- --0000000000001ae9a905c552c4c8 Content-Type: application/octet-stream; name="0001-Fix-NS-native-compilation-builds.patch" Content-Disposition: attachment; filename="0001-Fix-NS-native-compilation-builds.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kq7ilr0h0 RnJvbSBjMDYyNzQzNjYxNjM5YjA1YWRhNzYxOGIzOTY4MTgzMjk4ZjMzZDA2IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBNYXR0aGV3IEJhdWVyIDxtamJhdWVyOTVAZ21haWwuY29tPgpE YXRlOiBNb24sIDIxIEp1biAyMDIxIDIxOjE4OjA1IC0wNTAwClN1YmplY3Q6IFtQQVRDSF0gRml4 IE5TIG5hdGl2ZSBjb21waWxhdGlvbiBidWlsZHMKCiogTWFrZWZpbGUuaW4gKG5zX2FwcGRpcik6 IE5ldyB2YXJpYWJsZS4KKC5QSE9OWSk6IEluY2x1ZGUgbmV3IHJ1bGUuCihlcGF0aHMtZm9yY2Ut bnMtc2VsZi1jb250YWluZWQpOiBSZW1vdmUgdGhlIGFwcCBidW5kbGUgZGlyZWN0b3J5IGZyb20K YWxsIHBhdGhzLgoqIGNvbmZpZ3VyZS5hYyAoTlNfU0VMRl9DT05UQUlORUQpOiBTZXQgdGhlIGRl ZmF1bHQgc2l0ZS1saXNwCmRpcmVjdG9yeSBpbnN0ZWFkIG9mIGhhcmQtY29kaW5nIGl0IGluIHRo ZSBPYmpDIGNvZGUsIGFuZCB1c2UgdGhlIG5ldwplcGF0aHMgZ2VuZXJhdGluZyBtYWtlIHJ1bGUu Ciogc3JjL2NhbGxwcm9jLmMgKGluaXRfY2FsbHByb2NfMSk6Cihpbml0X2NhbGxwcm9jKTogUmVt b3ZlIGFsbCB0aGUgTlMgc3BlY2lmaWMgY29kZSBhcyB0aGUgc3BlY2lhbCBjYXNlcwphcmUgbm93 IGhhbmRsZWQgYnkgZGVjb2RlX2Vudl9wYXRoLgoqIHNyYy9lbWFjcy5jIChsb2FkX3BkdW1wKToK KGRlY29kZV9lbnZfcGF0aCk6IFVzZSBuc19yZWxvY2F0ZSB0byBmaW5kIHRoZSBjb3JyZWN0IGRp cmVjdG9yeSBhZnRlcgpyZWxvY2F0aW9uLgoqIHNyYy9scmVhZC5jIChsb2FkX3BhdGhfZGVmYXVs dCk6IFJlbW92ZSBhbGwgdGhlIE5TIHNwZWNpZmljIGNvZGUgYXMKdGhlIHNwZWNpYWwgY2FzZXMg YXJlIG5vdyBoYW5kbGVkIGJ5IGRlY29kZV9lbnZfcGF0aC4KKiBzcmMvbnN0ZXJtLmg6IFVwZGF0 ZSBmdW5jdGlvbiBkZWZpbml0aW9ucy4KKiBzcmMvbnN0ZXJtLm0gKG5zX2V0Y19kaXJlY3Rvcnkp OgoobnNfZXhlY19wYXRoKToKKG5zX2xvYWRfcGF0aCk6IFJlbW92ZSBmdW5jdGlvbnMgdGhhdCBh cmUgbm8gbG9uZ2VyIG5lZWRlZC4KKG5zX3JlbG9jYXRlKTogTmV3IGZ1bmN0aW9uIHRvIGNhbGN1 bGF0ZSBwYXRocyB3aXRoaW4gdGhlIE5TIGFwcApidW5kbGUuCi0tLQogTWFrZWZpbGUuaW4gICAg ICAgICAgfCAgMTcgKysrKystCiBjb25maWd1cmUuYWMgICAgICAgICB8ICAxMiArKystLQogbmV4 dHN0ZXAvTWFrZWZpbGUuaW4gfCAgMTMgKysrLS0KIHNyYy9jYWxscHJvYy5jICAgICAgIHwgIDM2 ICsrLS0tLS0tLS0tLS0KIHNyYy9lbWFjcy5jICAgICAgICAgIHwgIDE2ICsrKysrLQogc3JjL2xy ZWFkLmMgICAgICAgICAgfCAgIDcgKy0tCiBzcmMvbnN0ZXJtLmggICAgICAgICB8ICAgNCArLQog c3JjL25zdGVybS5tICAgICAgICAgfCAxMjUgKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQogOCBmaWxlcyBjaGFuZ2VkLCA3NCBpbnNlcnRpb25zKCspLCAxNTYgZGVs ZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvTWFrZWZpbGUuaW4gYi9NYWtlZmlsZS5pbgppbmRleCAz ZmFjZmE1OWE5Li42OGZlN2Q3ODFhIDEwMDY0NAotLS0gYS9NYWtlZmlsZS5pbgorKysgYi9NYWtl ZmlsZS5pbgpAQCAtMTA0LDggKzEwNCwxMCBAQCBIQVZFX05BVElWRV9DT01QID0gQEhBVkVfTkFU SVZFX0NPTVBACiAKICMgTG9jYXRpb24gdG8gaW5zdGFsbCBFbWFjcy5hcHAgdW5kZXIgR05Vc3Rl cCAvIG1hY09TLgogIyBMYXRlciB2YWx1ZXMgbWF5IHVzZSB0aGVzZS4KK25zX2FwcGRpcj1AbnNf YXBwZGlyQAogbnNfYXBwYmluZGlyPUBuc19hcHBiaW5kaXJACiBuc19hcHByZXNkaXI9QG5zX2Fw cHJlc2RpckAKK25zX2FwcGxpYmRpcj1AbnNfYXBwbGliZGlyQAogIyBFaXRoZXIgeWVzIG9yIG5v IGRlcGVuZGluZyBvbiB3aGV0aGVyIHRoaXMgaXMgYSByZWxvY2F0YWJsZSBFbWFjcy5hcHAuCiBu c19zZWxmX2NvbnRhaW5lZD1AbnNfc2VsZl9jb250YWluZWRACiAKQEAgLTMyOCwxMiArMzMwLDEy IEBAIEJJTl9ERVNURElSPSckKERFU1RESVIpJHtiaW5kaXJ9LycKIEVMTl9ERVNURElSID0gJChE RVNURElSKSR7bGliZGlyfS9lbWFjcy8ke3ZlcnNpb259LwogZWxzZQogQklOX0RFU1RESVI9JyR7 bnNfYXBwYmluZGlyfS8nCi1FTE5fREVTVERJUiA9ICR7bnNfYXBwcmVzZGlyfS8KK0VMTl9ERVNU RElSID0gJHtuc19hcHBsaWJkaXJ9L2VtYWNzLyR7dmVyc2lvbn0vCiBlbmRpZgogCiBhbGw6ICR7 U1VCRElSfSBpbmZvCiAKLS5QSE9OWTogYWxsICR7U1VCRElSfSBibGVzc21haWwgZXBhdGhzLWZv cmNlIGVwYXRocy1mb3JjZS13MzIgZXRjLWVtYWNzdmVyCisuUEhPTlk6IGFsbCAke1NVQkRJUn0g Ymxlc3NtYWlsIGVwYXRocy1mb3JjZSBlcGF0aHMtZm9yY2UtdzMyIGVwYXRocy1mb3JjZS1ucy1z ZWxmLWNvbnRhaW5lZCBldGMtZW1hY3N2ZXIKIAogIyBJZiBjb25maWd1cmUgd2VyZSB0byBqdXN0 IGdlbmVyYXRlIGVtYWNzdmVyLnRleCBmcm9tIGVtYWNzdmVyLnRleC5pbgogIyBpbiB0aGUgbm9y bWFsIHdheSwgdGhlIHRpbWVzdGFtcCBvZiBlbWFjc3Zlci50ZXggd291bGQgYWx3YXlzIGJlCkBA IC00MDIsNiArNDA0LDE3IEBAIGVwYXRocy1mb3JjZS13MzI6CiAJICAtZSAiL14uKiMvc3xAU1JD QHwkJHt3MzJzcmNkaXJ9fGciKSAmJgkJXAogCSR7c3JjZGlyfS9idWlsZC1hdXgvbW92ZS1pZi1j aGFuZ2UgZXBhdGhzLmguJCQkJCBzcmMvZXBhdGhzLmgKIAorIyBBIE5leHRTdGVwIHN0eWxlIGFw cCBidW5kbGUgaXMgcmVsb2NhdGFibGUsIHNvIGluc3RlYWQgb2YKKyMgaGFyZC1jb2RpbmcgcGF0 aHMgdHJ5IHRvIGdlbmVyYXRlIHRoZW0gYXQgcnVuLXRpbWUuCisjCisjIFRoZSBwYXRocyBhcmUg bW9zdGx5IHRoZSBzYW1lLCBhbmQgdGhlIGJ1bmRsZSBwYXRocyBhcmUgZGlmZmVyZW50CisjIGJl dHdlZW4gbWFjT1MgYW5kIEdOVXN0ZXAsIHNvIGp1c3QgcmVwbGFjZSBhbnkgcmVmZXJlbmNlcyB0 byB0aGUgYXBwCisjIGJ1bmRsZSByb290IGl0c2VsZiB3aXRoIHRoZSByZWxhdGl2ZSBwYXRoLgor ZXBhdGhzLWZvcmNlLW5zLXNlbGYtY29udGFpbmVkOiBlcGF0aHMtZm9yY2UKKwlAKHNlZCA8ICR7 c3JjZGlyfS9zcmMvZXBhdGhzLmggPiBlcGF0aHMuaC4kJCQkCVwKKwkgIC1lICdzOyR7bnNfYXBw ZGlyfS87OycpICYmCQkJXAorCSR7c3JjZGlyfS9idWlsZC1hdXgvbW92ZS1pZi1jaGFuZ2UgZXBh dGhzLmguJCQkJCBzcmMvZXBhdGhzLmgKKwogbGliLXNyYyBzcmM6ICQoTlRESVIpIGxpYgogCiBz cmM6IGxpYi1zcmMKZGlmZiAtLWdpdCBhL2NvbmZpZ3VyZS5hYyBiL2NvbmZpZ3VyZS5hYwppbmRl eCBjODI4ZjhkNzgyLi4wNWFmZGJjOGI4IDEwMDY0NAotLS0gYS9jb25maWd1cmUuYWMKKysrIGIv Y29uZmlndXJlLmFjCkBAIC0xODkxLDEwICsxODkxLDEwIEBAIGlmIHRlc3QgIiR7d2l0aF9uc30i ICE9IG5vOyB0aGVuCiAgICMgc28gYXZvaWQgTlNfSU1QTF9DT0NPQSBpZiBtYWN1dnMuaCBpcyBh YnNlbnQuCiAgICMgRXZlbiBhIGhlYWRsZXNzIEVtYWNzIGNhbiBidWlsZCBtYWN1dnMuaCwgc28g dGhpcyBzaG91bGQgbGV0IHlvdSBib290c3RyYXAuCiAgIGlmIHRlc3QgIiR7b3BzeXN9IiA9IGRh cndpbiAmJiB0ZXN0IC1mICIkc3JjZGlyL3NyYy9tYWN1dnMuaCI7IHRoZW4KLSAgICAgbGlzcGRp cnJlbD1Db250ZW50cy9SZXNvdXJjZXMvbGlzcAogICAgICBOU19JTVBMX0NPQ09BPXllcwogICAg ICBuc19hcHBkaXI9YHB3ZGAvbmV4dHN0ZXAvRW1hY3MuYXBwCiAgICAgIG5zX2FwcGJpbmRpcj0k e25zX2FwcGRpcn0vQ29udGVudHMvTWFjT1MKKyAgICAgbnNfYXBwbGliZGlyPSR7bnNfYXBwZGly fS9Db250ZW50cy9NYWNPUy9saWIKICAgICAgbnNfYXBwcmVzZGlyPSR7bnNfYXBwZGlyfS9Db250 ZW50cy9SZXNvdXJjZXMKICAgICAgbnNfYXBwc3JjPUNvY29hL0VtYWNzLmJhc2UKICAgICAgbnNf Zm9udGZpbGU9bWFjZm9udC5vCkBAIC0xOTUyLDYgKzE5NTIsNyBAQCBmYWlsOwogICBpZiB0ZXN0 ICROU19JTVBMX0dOVVNURVAgPSB5ZXM7IHRoZW4KICAgICAgbnNfYXBwZGlyPWBwd2RgL25leHRz dGVwL0VtYWNzLmFwcAogICAgICBuc19hcHBiaW5kaXI9JHtuc19hcHBkaXJ9CisgICAgIG5zX2Fw cGxpYmRpcj0ke25zX2FwcGRpcn0vbGliCiAgICAgIG5zX2FwcHJlc2Rpcj0ke25zX2FwcGRpcn0v UmVzb3VyY2VzCiAgICAgIG5zX2FwcHNyYz1HTlVzdGVwL0VtYWNzLmJhc2UKICAgICAgbnNfZm9u dGZpbGU9bnNmb250Lm8KQEAgLTIwMDgsNiArMjAwOSw3IEBAIGlmIHRlc3QgIiR7SEFWRV9OU30i ID0geWVzOyB0aGVuCiAgIHdpbmRvd19zeXN0ZW09bmV4dHN0ZXAKICAgIyBzZXQgdXAgcGFja2Fn aW5nIGRpcnMKICAgaWYgdGVzdCAiJHtFTl9OU19TRUxGX0NPTlRBSU5FRH0iID0geWVzOyB0aGVu CisgICAgIEFDX0RFRklORShOU19TRUxGX0NPTlRBSU5FRCwgMSwgW0J1aWxkIGFuIE5TIGJ1bmRs ZWQgYXBwXSkKICAgICAgbnNfc2VsZl9jb250YWluZWQ9eWVzCiAgICAgIHByZWZpeD0ke25zX2Fw cHJlc2Rpcn0KICAgICAgZXhlY19wcmVmaXg9JHtuc19hcHBiaW5kaXJ9CkBAIC0yMDIxLDcgKzIw MjMsNyBAQCBpZiB0ZXN0ICIke0hBVkVfTlN9IiA9IHllczsgdGhlbgogICAgICBpbmZvZGlyPSJc JHtuc19hcHByZXNkaXJ9L2luZm8iCiAgICAgIG1hbmRpcj0iXCR7bnNfYXBwcmVzZGlyfS9tYW4i CiAgICAgIGxpc3BkaXI9Ilwke25zX2FwcHJlc2Rpcn0vbGlzcCIKLSAgICAgdGVzdCAiJGxvY2Fs bGlzcHBhdGhzZXQiID0gbm8gJiYgbG9jYWxsaXNwcGF0aD0iIgorICAgICB0ZXN0ICIkbG9jYWxs aXNwcGF0aHNldCIgPSBubyAmJiBsb2NhbGxpc3BwYXRoPSJcJHtuc19hcHByZXNkaXJ9L3NpdGUt bGlzcCIKICAgICAgSU5TVEFMTF9BUkNIX0lOREVQX0VYVFJBPQogICBmaQogCkBAIC01NDA5LDYg KzU0MTEsNyBAQCBBQ19TVUJTVChDRkxBR1MpCiBBQ19TVUJTVChYX1RPT0xLSVRfVFlQRSkKIEFD X1NVQlNUKG5zX2FwcGRpcikKIEFDX1NVQlNUKG5zX2FwcGJpbmRpcikKK0FDX1NVQlNUKG5zX2Fw cGxpYmRpcikKIEFDX1NVQlNUKG5zX2FwcHJlc2RpcikKIEFDX1NVQlNUKG5zX2FwcHNyYykKIEFD X1NVQlNUKEdOVV9PQkpDX0NGTEFHUykKQEAgLTYwMDksMTAgKzYwMTIsMTMgQEAgZG5sIHRoZSB1 c2Ugb2YgZm9yY2UgaW4gdGhlICdlcGF0aHMtZm9yY2UnIHJ1bGUgaW4gTWFrZWZpbGUuaW4uCiBB Q19DT05GSUdfQ09NTUFORFMoW3NyYy9lcGF0aHMuaF0sIFsKIGlmIHRlc3QgIiR7b3BzeXN9IiA9 ICJtaW5ndzMyIjsgdGhlbgogICAke01BS0UtbWFrZX0gTUFLRUZJTEVfTkFNRT1kby1ub3QtbWFr ZS1NYWtlZmlsZSBlcGF0aHMtZm9yY2UtdzMyCitlbGlmIHRlc3QgIiRFTl9OU19TRUxGX0NPTlRB SU5FRCIgPSAieWVzIjsgdGhlbgorICAke01BS0UtbWFrZX0gTUFLRUZJTEVfTkFNRT1kby1ub3Qt bWFrZS1NYWtlZmlsZSBlcGF0aHMtZm9yY2UtbnMtc2VsZi1jb250YWluZWQKIGVsc2UKICAgJHtN QUtFLW1ha2V9IE1BS0VGSUxFX05BTUU9ZG8tbm90LW1ha2UtTWFrZWZpbGUgZXBhdGhzLWZvcmNl CiBmaSB8fCBBQ19NU0dfRVJST1IoWydzcmMvZXBhdGhzLmgnIGNvdWxkIG5vdCBiZSBtYWRlLl0p Ci1dLCBbR0NDPSIkR0NDIiBDUFBGTEFHUz0iJENQUEZMQUdTIiBvcHN5cz0iJG9wc3lzIl0pCitd LCBbR0NDPSIkR0NDIiBDUFBGTEFHUz0iJENQUEZMQUdTIiBvcHN5cz0iJG9wc3lzIgorICAgIEVO X05TX1NFTEZfQ09OVEFJTkVEPSIkRU5fTlNfU0VMRl9DT05UQUlORUQiXSkKIAogZG5sIE5CIHdl IGhhdmUgdG8gY2hlYXQgYW5kIHVzZSB0aGUgYWNfLi4uIHZlcnNpb24gYmVjYXVzZSBhYnNfdG9w X3NyY2RpcgogZG5sIGlzIG5vdCB5ZXQgc2V0LCBzaWdoLiAgT3Igd2UgY291bGQgdXNlIC4uLyRz cmNkaXIvc3JjLy5nZGJpbml0LApkaWZmIC0tZ2l0IGEvbmV4dHN0ZXAvTWFrZWZpbGUuaW4gYi9u ZXh0c3RlcC9NYWtlZmlsZS5pbgppbmRleCAzMTY4ZmVlNzZjLi44YTVjNjU2NTk3IDEwMDY0NAot LS0gYS9uZXh0c3RlcC9NYWtlZmlsZS5pbgorKysgYi9uZXh0c3RlcC9NYWtlZmlsZS5pbgpAQCAt MzIsMTkgKzMyLDIzIEBAIHRvcF9zcmNkaXJfYWJzID0gJChzaGVsbCBjZCBAdG9wX3NyY2RpckA7 IHB3ZCAtUCkKIAogTUtESVJfUCA9IEBNS0RJUl9QQAogCitwcmVmaXg9QHByZWZpeEAKK2V4ZWNf cHJlZml4PUBleGVjX3ByZWZpeEAKKwogIyMgRW1hY3MuYXBwLgogbnNfYXBwZGlyID0gQG5zX2Fw cGRpckAKICMjIEdOVXN0ZXA6IG5zX2FwcGRpcjsgbWFjT1M6IG5zX2FwcGRpci9Db250ZW50cy9N YWNPUwogbnNfYXBwYmluZGlyID0gQG5zX2FwcGJpbmRpckAKICMjIEdOVXN0ZXAvRW1hY3MuYmFz ZSBvciBDb2NvYS9FbWFjcy5iYXNlLgogbnNfYXBwc3JjID0gQG5zX2FwcHNyY0AKK25zX2FwcGxp YmV4ZWNkaXIgPSBAbGliZXhlY2RpckAKICMjIEdOVXN0ZXA6IEdOVXN0ZXAvRW1hY3MuYmFzZS9S ZXNvdXJjZXMvSW5mby1nbnVzdGVwLnBsaXN0CiAjIyBtYWNPUzogQ29jb2EvRW1hY3MuYmFzZS9D b250ZW50cy9JbmZvLnBsaXN0CiBuc19jaGVja19maWxlID0gQG5zX2FwcGRpckAvQG5zX2NoZWNr X2ZpbGVACiAKIC5QSE9OWTogYWxsCiAKLWFsbDogJHtuc19hcHBkaXJ9ICR7bnNfYXBwYmluZGly fS9FbWFjcyAke25zX2FwcGJpbmRpcn0vRW1hY3MucGRtcAorYWxsOiAke25zX2FwcGRpcn0gJHtu c19hcHBiaW5kaXJ9L0VtYWNzICR7bnNfYXBwbGliZXhlY2Rpcn0vRW1hY3MucGRtcAogCiAke25z X2NoZWNrX2ZpbGV9ICR7bnNfYXBwZGlyfTogJHtzcmNkaXJ9LyR7bnNfYXBwc3JjfSAke25zX2Fw cHNyY30KIAlybSAtcmYgJHtuc19hcHBkaXJ9CkBAIC02Myw4ICs2Nyw4IEBAICR7bnNfYXBwYmlu ZGlyfS9FbWFjczogJHtuc19hcHBkaXJ9ICR7bnNfY2hlY2tfZmlsZX0gLi4vc3JjL2VtYWNzJHtF WEVFWFR9CiAJJHtNS0RJUl9QfSAke25zX2FwcGJpbmRpcn0KIAljcCAtZiAuLi9zcmMvZW1hY3Mk e0VYRUVYVH0gJEAKIAotJHtuc19hcHBiaW5kaXJ9L0VtYWNzLnBkbXA6ICR7bnNfYXBwZGlyfSAk e25zX2NoZWNrX2ZpbGV9IC4uL3NyYy9lbWFjcyR7RVhFRVhUfS5wZG1wCi0JJHtNS0RJUl9QfSAk e25zX2FwcGJpbmRpcn0KKyR7bnNfYXBwbGliZXhlY2Rpcn0vRW1hY3MucGRtcDogJHtuc19hcHBk aXJ9ICR7bnNfY2hlY2tfZmlsZX0gLi4vc3JjL2VtYWNzJHtFWEVFWFR9LnBkbXAKKwkke01LRElS X1B9ICR7bnNfYXBwbGliZXhlY2Rpcn0KIAljcCAtZiAuLi9zcmMvZW1hY3Mke0VYRUVYVH0ucGRt cCAkQAogCiAuUEhPTlk6IEZPUkNFCkBAIC04NSw5ICs4OSw4IEBAIGxpbmtzOiAuLi9zcmMvZW1h Y3Mke0VYRUVYVH0KIAlsbiAtcyAkKHRvcF9zcmNkaXJfYWJzKS9pbmZvICR7bnNfYXBwZGlyfS9D b250ZW50cy9SZXNvdXJjZXMKIAkke01LRElSX1B9ICR7bnNfYXBwYmluZGlyfQogCWxuIC1zICQo YWJzX3RvcF9idWlsZGRpcikvc3JjL2VtYWNzJHtFWEVFWFR9ICR7bnNfYXBwYmluZGlyfS9FbWFj cwotCWxuIC1zICQoYWJzX3RvcF9idWlsZGRpcikvc3JjL2VtYWNzJHtFWEVFWFR9LnBkbXAgJHtu c19hcHBiaW5kaXJ9L0VtYWNzLnBkbXAKIAlsbiAtcyAkKGFic190b3BfYnVpbGRkaXIpL2xpYi1z cmMgJHtuc19hcHBiaW5kaXJ9L2JpbgotCWxuIC1zICQoYWJzX3RvcF9idWlsZGRpcikvbGliLXNy YyAke25zX2FwcGJpbmRpcn0vbGliZXhlYworCWxuIC1zICQoYWJzX3RvcF9idWlsZGRpcikvbGli LXNyYyAke25zX2FwcGxpYmV4ZWNkaXJ9CiAJJHtNS0RJUl9QfSAke25zX2FwcGRpcn0vQ29udGVu dHMvUmVzb3VyY2VzL2V0YwogCWZvciBmIGluICQoc2hlbGwgY2QgJCh0b3Bfc3JjZGlyX2Ficykv ZXRjOyBscyk7IGRvIGxuIC1zICQodG9wX3NyY2Rpcl9hYnMpL2V0Yy8kJGYgJHtuc19hcHBkaXJ9 L0NvbnRlbnRzL1Jlc291cmNlcy9ldGM7IGRvbmUKIAlsbiAtcyAkKGFic190b3BfYnVpbGRkaXIp L2V0Yy9ET0MgJHtuc19hcHBkaXJ9L0NvbnRlbnRzL1Jlc291cmNlcy9ldGMKZGlmZiAtLWdpdCBh L3NyYy9jYWxscHJvYy5jIGIvc3JjL2NhbGxwcm9jLmMKaW5kZXggZTQ0ZTI0MzY4MC4uYWFiYzM5 MzEzYiAxMDA2NDQKLS0tIGEvc3JjL2NhbGxwcm9jLmMKKysrIGIvc3JjL2NhbGxwcm9jLmMKQEAg LTE2NjEsMzIgKzE2NjEsMTUgQEAgbWFrZV9lbnZpcm9ubWVudF9ibG9jayAoTGlzcF9PYmplY3Qg Y3VycmVudF9kaXIpCiB2b2lkCiBpbml0X2NhbGxwcm9jXzEgKHZvaWQpCiB7Ci0jaWZkZWYgSEFW RV9OUwotICBjb25zdCBjaGFyICpldGNfZGlyID0gbnNfZXRjX2RpcmVjdG9yeSAoKTsKLSAgY29u c3QgY2hhciAqcGF0aF9leGVjID0gbnNfZXhlY19wYXRoICgpOwotI2VuZGlmCi0KLSAgVmRhdGFf ZGlyZWN0b3J5ID0gZGVjb2RlX2Vudl9wYXRoICgiRU1BQ1NEQVRBIiwKLSNpZmRlZiBIQVZFX05T Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBldGNfZGlyID8g ZXRjX2RpciA6Ci0jZW5kaWYKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFBBVEhfREFUQSwgMCk7CisgIFZkYXRhX2RpcmVjdG9yeSA9IGRlY29kZV9lbnZfcGF0 aCAoIkVNQUNTREFUQSIsIFBBVEhfREFUQSwgMCk7CiAgIFZkYXRhX2RpcmVjdG9yeSA9IEZmaWxl X25hbWVfYXNfZGlyZWN0b3J5IChGY2FyIChWZGF0YV9kaXJlY3RvcnkpKTsKIAotICBWZG9jX2Rp cmVjdG9yeSA9IGRlY29kZV9lbnZfcGF0aCAoIkVNQUNTRE9DIiwKLSNpZmRlZiBIQVZFX05TCi0g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBldGNfZGlyID8gZXRj X2RpciA6Ci0jZW5kaWYKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFBBVEhfRE9DLCAwKTsKKyAgVmRvY19kaXJlY3RvcnkgPSBkZWNvZGVfZW52X3BhdGggKCJF TUFDU0RPQyIsIFBBVEhfRE9DLCAwKTsKICAgVmRvY19kaXJlY3RvcnkgPSBGZmlsZV9uYW1lX2Fz X2RpcmVjdG9yeSAoRmNhciAoVmRvY19kaXJlY3RvcnkpKTsKIAogICAvKiBDaGVjayB0aGUgRU1B Q1NQQVRIIGVudmlyb25tZW50IHZhcmlhYmxlLCBkZWZhdWx0aW5nIHRvIHRoZQogICAgICBQQVRI X0VYRUMgcGF0aCBmcm9tIGVwYXRocy5oLiAgKi8KLSAgVmV4ZWNfcGF0aCA9IGRlY29kZV9lbnZf cGF0aCAoIkVNQUNTUEFUSCIsCi0jaWZkZWYgSEFWRV9OUwotICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBwYXRoX2V4ZWMgPyBwYXRoX2V4ZWMgOgotI2VuZGlmCi0gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFBBVEhfRVhFQywgMCk7CisgIFZleGVjX3BhdGggPSBkZWNvZGVf ZW52X3BhdGggKCJFTUFDU1BBVEgiLCBQQVRIX0VYRUMsIDApOwogICBWZXhlY19kaXJlY3Rvcnkg PSBGZmlsZV9uYW1lX2FzX2RpcmVjdG9yeSAoRmNhciAoVmV4ZWNfcGF0aCkpOwogICAvKiBGSVhN RT8gIEZvciBucywgcGF0aF9leGVjIHNob3VsZCBnbyBhdCB0aGUgZnJvbnQ/ICAqLwogICBWZXhl Y19wYXRoID0gbmNvbmMyIChkZWNvZGVfZW52X3BhdGggKCJQQVRIIiwgIiIsIDApLCBWZXhlY19w YXRoKTsKQEAgLTE3MDEsMTAgKzE2ODQsNiBAQCBpbml0X2NhbGxwcm9jICh2b2lkKQogCiAgIGNo YXIgKnNoOwogICBMaXNwX09iamVjdCB0ZW1wZGlyOwotI2lmZGVmIEhBVkVfTlMKLSAgaWYgKGRh dGFfZGlyID09IDApCi0gICAgZGF0YV9kaXIgPSBuc19ldGNfZGlyZWN0b3J5ICgpICE9IDA7Ci0j ZW5kaWYKIAogICBpZiAoIU5JTFAgKFZpbnN0YWxsYXRpb25fZGlyZWN0b3J5KSkKICAgICB7CkBA IC0xNzE2LDE1ICsxNjk1LDggQEAgaW5pdF9jYWxscHJvYyAodm9pZCkKIAkgIC8qIE1TRE9TIHVz ZXMgd3JhcHBlZCBiaW5hcmllcywgc28gZG9uJ3QgZG8gdGhpcy4gICovCiAgICAgICBpZiAoTklM UCAoRm1lbWJlciAodGVtLCBWZXhlY19wYXRoKSkpCiAJewotI2lmZGVmIEhBVkVfTlMKLQkgIGNv bnN0IGNoYXIgKnBhdGhfZXhlYyA9IG5zX2V4ZWNfcGF0aCAoKTsKLSNlbmRpZgogCSAgLyogUnVu bmluZyB1bmluc3RhbGxlZCwgc28gZGVmYXVsdCB0byB0ZW0gcmF0aGVyIHRoYW4gUEFUSF9FWEVD LiAgKi8KLQkgIFZleGVjX3BhdGggPSBkZWNvZGVfZW52X3BhdGggKCJFTUFDU1BBVEgiLAotI2lm ZGVmIEhBVkVfTlMKLQkJCQkJcGF0aF9leGVjID8gcGF0aF9leGVjIDoKLSNlbmRpZgotCQkJCQlT U0RBVEEgKHRlbSksIDApOworCSAgVmV4ZWNfcGF0aCA9IGRlY29kZV9lbnZfcGF0aCAoIkVNQUNT UEFUSCIsIFNTREFUQSAodGVtKSwgMCk7CiAJICBWZXhlY19wYXRoID0gbmNvbmMyIChkZWNvZGVf ZW52X3BhdGggKCJQQVRIIiwgIiIsIDApLCBWZXhlY19wYXRoKTsKIAl9CiAKZGlmZiAtLWdpdCBh L3NyYy9lbWFjcy5jIGIvc3JjL2VtYWNzLmMKaW5kZXggNjBhNTdhNjkzYy4uYjc5ODJlY2U2NCAx MDA2NDQKLS0tIGEvc3JjL2VtYWNzLmMKKysrIGIvc3JjL2VtYWNzLmMKQEAgLTgzNSw3ICs4MzUs MTMgQEAgbG9hZF9wZHVtcCAoaW50IGFyZ2MsIGNoYXIgKiphcmd2KQogICAgIE5VTEwKICNlbmRp ZgogICAgIDsKLSAgY29uc3QgY2hhciAqYXJndjBfYmFzZSA9ICJlbWFjcyI7CisgIGNvbnN0IGNo YXIgKmFyZ3YwX2Jhc2UgPQorI2lmZGVmIE5TX1NFTEZfQ09OVEFJTkVECisgICAgIkVtYWNzIgor I2Vsc2UKKyAgICAiZW1hY3MiCisjZW5kaWYKKyAgICA7CiAKICAgLyogVE9ETzogbWF5YmUgbW9y ZSB0aG9yb3VnaGx5IHNjcnViIHByb2Nlc3MgZW52aXJvbm1lbnQgaW4gb3JkZXIgdG8KICAgICAg bWFrZSB0aGlzIHVzZSBjYXNlIChsb2FkaW5nIGEgZHVtcCBmaWxlIGluIGFuIHVuZXhlY2VkIGVt YWNzKQpAQCAtOTEyLDYgKzkxOCw4IEBAIGxvYWRfcGR1bXAgKGludCBhcmdjLCBjaGFyICoqYXJn dikKICAgLyogT24gTVMtV2luZG93cywgUEFUSF9FWEVDIG5vcm1hbGx5IHN0YXJ0cyB3aXRoIGEg bGl0ZXJhbAogICAgICAiJWVtYWNzX2RpciUiLCBzbyBpdCB3aWxsIG5ldmVyIHdvcmsgd2l0aG91 dCBzb21lIHR3ZWFraW5nLiAgKi8KICAgcGF0aF9leGVjID0gdzMyX3JlbG9jYXRlIChwYXRoX2V4 ZWMpOworI2VsaWYgZGVmaW5lZCAoSEFWRV9OUykKKyAgcGF0aF9leGVjID0gbnNfcmVsb2NhdGUg KHBhdGhfZXhlYyk7CiAjZW5kaWYKIAogICAvKiBMb29rIGZvciAiZW1hY3MucGRtcCIgaW4gUEFU SF9FWEVDLiAgV2UgaGFyZGNvZGUgImVtYWNzIiBpbgpAQCAtOTI5LDYgKzkzNyw3IEBAIGxvYWRf cGR1bXAgKGludCBhcmdjLCBjaGFyICoqYXJndikKICAgICB9CiAgIHNwcmludGYgKGR1bXBfZmls ZSwgIiVzJWMlcyVzIiwKICAgICAgICAgICAgcGF0aF9leGVjLCBESVJFQ1RPUllfU0VQLCBhcmd2 MF9iYXNlLCBzdWZmaXgpOworI2lmICFkZWZpbmVkIChOU19TRUxGX0NPTlRBSU5FRCkKICAgLyog QXNzdW1lIHRoZSBFbWFjcyBiaW5hcnkgbGl2ZXMgaW4gYSBzaWJsaW5nIGRpcmVjdG9yeSBhcyBz ZXQgdXAgYnkKICAgICAgdGhlIGRlZmF1bHQgaW5zdGFsbGF0aW9uIGNvbmZpZ3VyYXRpb24uICAq LwogICBjb25zdCBjaGFyICpnb191cCA9ICIuLi8uLi8uLi8uLi9iaW4vIjsKQEAgLTk0Myw2ICs5 NTIsNyBAQCBsb2FkX3BkdW1wIChpbnQgYXJnYywgY2hhciAqKmFyZ3YpCiAgIHNwcmludGYgKGVt YWNzX2V4ZWN1dGFibGUsICIlcyVjJXMlcyVzIiwKIAkgICBwYXRoX2V4ZWMsIERJUkVDVE9SWV9T RVAsIGdvX3VwLCBhcmd2MF9iYXNlLAogCSAgIHN0cmlwX3N1ZmZpeCA/IHN0cmlwX3N1ZmZpeCA6 ICIiKTsKKyNlbmRpZgogICByZXN1bHQgPSBwZHVtcGVyX2xvYWQgKGR1bXBfZmlsZSwgZW1hY3Nf ZXhlY3V0YWJsZSk7CiAKICAgaWYgKHJlc3VsdCA9PSBQRFVNUEVSX0xPQURfRklMRV9OT1RfRk9V TkQpCkBAIC0yOTYwLDcgKzI5NzAsMTEgQEAgZGVjb2RlX2Vudl9wYXRoIChjb25zdCBjaGFyICpl dmFybmFtZSwgY29uc3QgY2hhciAqZGVmYWx0LCBib29sIGVtcHR5KQogICAgIHBhdGggPSAwOwog ICBpZiAoIXBhdGgpCiAgICAgeworI2lmZGVmIE5TX1NFTEZfQ09OVEFJTkVECisgICAgICBwYXRo ID0gbnNfcmVsb2NhdGUgKGRlZmFsdCk7CisjZWxzZQogICAgICAgcGF0aCA9IGRlZmFsdDsKKyNl bmRpZgogI2lmZGVmIFdJTkRPV1NOVAogICAgICAgZGVmYXVsdGVkID0gMTsKICNlbmRpZgpkaWZm IC0tZ2l0IGEvc3JjL2xyZWFkLmMgYi9zcmMvbHJlYWQuYwppbmRleCAwYjMzZmQwZjI1Li40NjE3 ZmZkNjI2IDEwMDY0NAotLS0gYS9zcmMvbHJlYWQuYworKysgYi9zcmMvbHJlYWQuYwpAQCAtNDc2 OSwxNCArNDc2OSw5IEBAIGxvYWRfcGF0aF9kZWZhdWx0ICh2b2lkKQogICAgIHJldHVybiBkZWNv ZGVfZW52X3BhdGggKDAsIFBBVEhfRFVNUExPQURTRUFSQ0gsIDApOwogCiAgIExpc3BfT2JqZWN0 IGxwYXRoID0gUW5pbDsKLSAgY29uc3QgY2hhciAqbm9ybWFsID0gUEFUSF9MT0FEU0VBUkNIOwog ICBjb25zdCBjaGFyICpsb2FkcGF0aCA9IE5VTEw7CiAKLSNpZmRlZiBIQVZFX05TCi0gIGxvYWRw YXRoID0gbnNfbG9hZF9wYXRoICgpOwotI2VuZGlmCi0KLSAgbHBhdGggPSBkZWNvZGVfZW52X3Bh dGggKDAsIGxvYWRwYXRoID8gbG9hZHBhdGggOiBub3JtYWwsIDApOworICBscGF0aCA9IGRlY29k ZV9lbnZfcGF0aCAoMCwgUEFUSF9MT0FEU0VBUkNILCAwKTsKIAogICBpZiAoIU5JTFAgKFZpbnN0 YWxsYXRpb25fZGlyZWN0b3J5KSkKICAgICB7CmRpZmYgLS1naXQgYS9zcmMvbnN0ZXJtLmggYi9z cmMvbnN0ZXJtLmgKaW5kZXggZjY0MzU0YjhhNy4uYjI5ZTc2Y2M2MyAxMDA2NDQKLS0tIGEvc3Jj L25zdGVybS5oCisrKyBiL3NyYy9uc3Rlcm0uaApAQCAtMTE5MCw5ICsxMTkwLDcgQEAgZXh0ZXJu IHZvaWQgbnNfcnVuX2FzY3JpcHQgKHZvaWQpOwogI2RlZmluZSBOU0FQUF9EQVRBMl9SVU5GSUxF RElBTE9HIDExCiBleHRlcm4gdm9pZCBuc19ydW5fZmlsZV9kaWFsb2cgKHZvaWQpOwogCi1leHRl cm4gY29uc3QgY2hhciAqbnNfZXRjX2RpcmVjdG9yeSAodm9pZCk7Ci1leHRlcm4gY29uc3QgY2hh ciAqbnNfZXhlY19wYXRoICh2b2lkKTsKLWV4dGVybiBjb25zdCBjaGFyICpuc19sb2FkX3BhdGgg KHZvaWQpOworZXh0ZXJuIGNvbnN0IGNoYXIgKm5zX3JlbG9jYXRlIChjb25zdCBjaGFyICplcGF0 aCk7CiBleHRlcm4gdm9pZCBzeW1zX29mX25zdGVybSAodm9pZCk7CiBleHRlcm4gdm9pZCBzeW1z X29mX25zZm5zICh2b2lkKTsKIGV4dGVybiB2b2lkIHN5bXNfb2ZfbnNtZW51ICh2b2lkKTsKZGlm ZiAtLWdpdCBhL3NyYy9uc3Rlcm0ubSBiL3NyYy9uc3Rlcm0ubQppbmRleCBlODFhNGNiYzBkLi5l MWEyMTlhMTNiIDEwMDY0NAotLS0gYS9zcmMvbnN0ZXJtLm0KKysrIGIvc3JjL25zdGVybS5tCkBA IC00OTksMTE4ICs0OTksMzUgQEAgLSAoTlNDb2xvciAqKWNvbG9yVXNpbmdEZWZhdWx0Q29sb3JT cGFjZQogCiAKIGNvbnN0IGNoYXIgKgotbnNfZXRjX2RpcmVjdG9yeSAodm9pZCkKLS8qIElmIHJ1 bm5pbmcgYXMgYSBzZWxmLWNvbnRhaW5lZCBhcHAgYnVuZGxlLCByZXR1cm4gYXMgYSBzdHJpbmcg dGhlCi0gICBmaWxlbmFtZSBvZiB0aGUgZXRjIGRpcmVjdG9yeSwgaWYgcHJlc2VudDsgZWxzZSBu aWwuICAqLwotewotICBOU0J1bmRsZSAqYnVuZGxlID0gW05TQnVuZGxlIG1haW5CdW5kbGVdOwot ICBOU1N0cmluZyAqcmVzb3VyY2VEaXIgPSBbYnVuZGxlIHJlc291cmNlUGF0aF07Ci0gIE5TU3Ry aW5nICpyZXNvdXJjZVBhdGg7Ci0gIE5TRmlsZU1hbmFnZXIgKmZpbGVNYW5hZ2VyID0gW05TRmls ZU1hbmFnZXIgZGVmYXVsdE1hbmFnZXJdOwotICBCT09MIGlzRGlyOworbnNfcmVsb2NhdGUgKGNv bnN0IGNoYXIgKmVwYXRoKQorLyogSWYgd2UncmUgcnVubmluZyBpbiBhIHNlbGYtY29udGFpbmVk IGFwcCBidW5kbGUgc29tZSBoYXJkLWNvZGVkCisgICBwYXRocyBhcmUgcmVsYXRpdmUgdG8gdGhl IHJvb3Qgb2YgdGhlIGJ1bmRsZSwgc28gd29yayBvdXQgdGhlIGZ1bGwKKyAgIHBhdGguCiAKLSAg cmVzb3VyY2VQYXRoID0gW3Jlc291cmNlRGlyIHN0cmluZ0J5QXBwZW5kaW5nUGF0aENvbXBvbmVu dDogQCJldGMiXTsKLSAgaWYgKFtmaWxlTWFuYWdlciBmaWxlRXhpc3RzQXRQYXRoOiByZXNvdXJj ZVBhdGggaXNEaXJlY3Rvcnk6ICZpc0Rpcl0pCi0gICAgewotICAgICAgaWYgKGlzRGlyKSByZXR1 cm4gW3Jlc291cmNlUGF0aCBVVEY4U3RyaW5nXTsKLSAgICB9Ci0gIHJldHVybiBOVUxMOwotfQot Ci0KLWNvbnN0IGNoYXIgKgotbnNfZXhlY19wYXRoICh2b2lkKQotLyogSWYgcnVubmluZyBhcyBh IHNlbGYtY29udGFpbmVkIGFwcCBidW5kbGUsIHJldHVybiBhcyBhIHBhdGggc3RyaW5nCi0gICB0 aGUgZmlsZW5hbWVzIG9mIHRoZSBsaWJleGVjIGFuZCBiaW4gZGlyZWN0b3JpZXMsIGllIGxpYmV4 ZWM6YmluLgotICAgT3RoZXJ3aXNlLCByZXR1cm4gbmlsLgotICAgTm9ybWFsbHksIEVtYWNzIGRv ZXMgbm90IGFkZCBpdHMgb3duIGJpbi8gZGlyZWN0b3J5IHRvIHRoZSBQQVRILgotICAgSG93ZXZl ciwgYSBzZWxmLWNvbnRhaW5lZCBOUyBidWlsZCBoYXMgYSBkaWZmZXJlbnQgbGF5b3V0LCB3aXRo Ci0gICBiaW4vIGFuZCBsaWJleGVjLyBzdWJkaXJlY3RvcmllcyBpbiB0aGUgZGlyZWN0b3J5IHRo YXQgY29udGFpbnMKLSAgIEVtYWNzLmFwcCBpdHNlbGYuCi0gICBXZSBwdXQgbGliZXhlYyBmaXJz dCwgYmVjYXVzZSBpbml0X2NhbGxwcm9jXzEgdXNlcyB0aGUgZmlyc3QKLSAgIGVsZW1lbnQgdG8g aW5pdGlhbGl6ZSBleGVjLWRpcmVjdG9yeS4gIEFuIGFsdGVybmF0aXZlIHdvdWxkIGJlCi0gICBm b3IgaW5pdF9jYWxscHJvYyB0byBjaGVjayBmb3IgaW52b2NhdGlvbi1kaXJlY3RvcnkvbGliZXhl Yy4KLSovCisgICBGSVhNRTogSSB0aGluayB0aGlzIHNob3VsZCBiZSBhYmxlIHRvIGhhbmRsZSBj YXNlcyB3aGVyZSBtdWx0aXBsZQorICAgZGlyZWN0b3JpZXMgYXJlIHNlcGFyYXRlZCBieSBjb2xv bnMuICAqLwogeworI2lmZGVmIE5TX1NFTEZfQ09OVEFJTkVECiAgIE5TQnVuZGxlICpidW5kbGUg PSBbTlNCdW5kbGUgbWFpbkJ1bmRsZV07Ci0gIE5TU3RyaW5nICpyZXNvdXJjZURpciA9IFtidW5k bGUgcmVzb3VyY2VQYXRoXTsKLSAgTlNTdHJpbmcgKmJpbkRpciA9IFtidW5kbGUgYnVuZGxlUGF0 aF07Ci0gIE5TU3RyaW5nICpyZXNvdXJjZVBhdGgsICpyZXNvdXJjZVBhdGhzOwotICBOU1Jhbmdl IHJhbmdlOwotICBOU1N0cmluZyAqcGF0aFNlcGFyYXRvciA9IFtOU1N0cmluZyBzdHJpbmdXaXRo Rm9ybWF0OiBAIiVjIiwgU0VQQ0hBUl07CisgIE5TU3RyaW5nICpyb290ID0gW2J1bmRsZSBidW5k bGVQYXRoXTsKKyAgTlNTdHJpbmcgKm9yaWdpbmFsID0gW05TU3RyaW5nIHN0cmluZ1dpdGhVVEY4 U3RyaW5nOmVwYXRoXTsKKyAgTlNTdHJpbmcgKmZpeGVkUGF0aCA9IFtOU1N0cmluZyBwYXRoV2l0 aENvbXBvbmVudHM6QFtyb290LCBvcmlnaW5hbF1dOwogICBOU0ZpbGVNYW5hZ2VyICpmaWxlTWFu YWdlciA9IFtOU0ZpbGVNYW5hZ2VyIGRlZmF1bHRNYW5hZ2VyXTsKLSAgTlNBcnJheSAqcGF0aHM7 Ci0gIE5TRW51bWVyYXRvciAqcGF0aEVudW07Ci0gIEJPT0wgaXNEaXI7CiAKLSAgcmFuZ2UgPSBb cmVzb3VyY2VEaXIgcmFuZ2VPZlN0cmluZzogQCJDb250ZW50cyJdOwotICBpZiAocmFuZ2UubG9j YXRpb24gIT0gTlNOb3RGb3VuZCkKLSAgICB7Ci0gICAgICBiaW5EaXIgPSBbYmluRGlyIHN0cmlu Z0J5QXBwZW5kaW5nUGF0aENvbXBvbmVudDogQCJDb250ZW50cyJdOwotI2lmZGVmIE5TX0lNUExf Q09DT0EKLSAgICAgIGJpbkRpciA9IFtiaW5EaXIgc3RyaW5nQnlBcHBlbmRpbmdQYXRoQ29tcG9u ZW50OiBAIk1hY09TIl07Ci0jZW5kaWYKLSAgICB9CisgIGlmICghW29yaWdpbmFsIGlzQWJzb2x1 dGVQYXRoXQorICAgICAgJiYgW2ZpbGVNYW5hZ2VyIGZpbGVFeGlzdHNBdFBhdGg6Zml4ZWRQYXRo IGlzRGlyZWN0b3J5Om5pbF0pCisgICAgcmV0dXJuIFtmaXhlZFBhdGggVVRGOFN0cmluZ107CiAK LSAgcGF0aHMgPSBbYmluRGlyIHN0cmluZ3NCeUFwcGVuZGluZ1BhdGhzOgotICAgICAgICAgICAg ICAgIFtOU0FycmF5IGFycmF5V2l0aE9iamVjdHM6IEAibGliZXhlYyIsIEAiYmluIiwgbmlsXV07 Ci0gIHBhdGhFbnVtID0gW3BhdGhzIG9iamVjdEVudW1lcmF0b3JdOwotICByZXNvdXJjZVBhdGhz ID0gQCIiOworICAvKiBJZiB3ZSByZWFjaCBoZXJlIGVpdGhlciB0aGUgcGF0aCBpcyBhYnNvbHV0 ZSBhbmQgdGhlcmVmb3JlIHdlCisgICAgIGRvbid0IG5lZWQgdG8gY29tcGxldGUgaXQsIG9yIHdl J3JlIHVuYWJsZSB0byByZWxvY2F0ZSB0aGUKKyAgICAgZmlsZS9kaXJlY3RvcnkuICBJZiBpdCdz IHRoZSBsYXR0ZXIgaXQgbWF5IGJlIGJlY2F1c2UgdGhlIHVzZXIgaXMKKyAgICAgdHJ5aW5nIHRv IHVzZSBhIGJ1bmRsZWQgYXBwIGFzIHRob3VnaCBpdCdzIGEgVW5peCBzdHlsZSBpbnN0YWxsCisg ICAgIGFuZCB3ZSBoYXZlIG5vIHdheSB0byBndWVzcyB3aGF0IHdhcyBpbnRlbmRlZCwgc28gcmV0 dXJuIHRoZQorICAgICBvcmlnaW5hbCBzdHJpbmcgdW5hbHRlcmVkLiAgKi8KIAotICB3aGlsZSAo KHJlc291cmNlUGF0aCA9IFtwYXRoRW51bSBuZXh0T2JqZWN0XSkpCi0gICAgewotICAgICAgaWYg KFtmaWxlTWFuYWdlciBmaWxlRXhpc3RzQXRQYXRoOiByZXNvdXJjZVBhdGggaXNEaXJlY3Rvcnk6 ICZpc0Rpcl0pCi0gICAgICAgIGlmIChpc0RpcikKLSAgICAgICAgICB7Ci0gICAgICAgICAgICBp ZiAoW3Jlc291cmNlUGF0aHMgbGVuZ3RoXSA+IDApCi0gICAgICAgICAgICAgIHJlc291cmNlUGF0 aHMKLSAgICAgICAgICAgICAgICA9IFtyZXNvdXJjZVBhdGhzIHN0cmluZ0J5QXBwZW5kaW5nU3Ry aW5nOiBwYXRoU2VwYXJhdG9yXTsKLSAgICAgICAgICAgIHJlc291cmNlUGF0aHMKLSAgICAgICAg ICAgICAgPSBbcmVzb3VyY2VQYXRocyBzdHJpbmdCeUFwcGVuZGluZ1N0cmluZzogcmVzb3VyY2VQ YXRoXTsKLSAgICAgICAgICB9Ci0gICAgfQotICBpZiAoW3Jlc291cmNlUGF0aHMgbGVuZ3RoXSA+ IDApIHJldHVybiBbcmVzb3VyY2VQYXRocyBVVEY4U3RyaW5nXTsKLQotICByZXR1cm4gTlVMTDsK LX0KLQotCi1jb25zdCBjaGFyICoKLW5zX2xvYWRfcGF0aCAodm9pZCkKLS8qIElmIHJ1bm5pbmcg YXMgYSBzZWxmLWNvbnRhaW5lZCBhcHAgYnVuZGxlLCByZXR1cm4gYXMgYSBwYXRoIHN0cmluZwot ICAgdGhlIGZpbGVuYW1lcyBvZiB0aGUgc2l0ZS1saXNwIGFuZCBsaXNwIGRpcmVjdG9yaWVzLgot ICAgSWUsIHNpdGUtbGlzcDpsaXNwLiAgT3RoZXJ3aXNlLCByZXR1cm4gbmlsLiAgKi8KLXsKLSAg TlNCdW5kbGUgKmJ1bmRsZSA9IFtOU0J1bmRsZSBtYWluQnVuZGxlXTsKLSAgTlNTdHJpbmcgKnJl c291cmNlRGlyID0gW2J1bmRsZSByZXNvdXJjZVBhdGhdOwotICBOU1N0cmluZyAqcmVzb3VyY2VQ YXRoLCAqcmVzb3VyY2VQYXRoczsKLSAgTlNTdHJpbmcgKnBhdGhTZXBhcmF0b3IgPSBbTlNTdHJp bmcgc3RyaW5nV2l0aEZvcm1hdDogQCIlYyIsIFNFUENIQVJdOwotICBOU0ZpbGVNYW5hZ2VyICpm aWxlTWFuYWdlciA9IFtOU0ZpbGVNYW5hZ2VyIGRlZmF1bHRNYW5hZ2VyXTsKLSAgQk9PTCBpc0Rp cjsKLSAgTlNBcnJheSAqcGF0aHMgPSBbcmVzb3VyY2VEaXIgc3RyaW5nc0J5QXBwZW5kaW5nUGF0 aHM6Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbTlNBcnJheSBhcnJheVdpdGhPYmpl Y3RzOgotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBAInNpdGUtbGlz cCIsIEAibGlzcCIsIG5pbF1dOwotICBOU0VudW1lcmF0b3IgKnBhdGhFbnVtID0gW3BhdGhzIG9i amVjdEVudW1lcmF0b3JdOwotICByZXNvdXJjZVBhdGhzID0gQCIiOwotCi0gIC8qIEhhY2sgdG8g c2tpcCBzaXRlLWxpc3AuICAqLwotICBpZiAobm9fc2l0ZV9saXNwKSByZXNvdXJjZVBhdGggPSBb cGF0aEVudW0gbmV4dE9iamVjdF07Ci0KLSAgd2hpbGUgKChyZXNvdXJjZVBhdGggPSBbcGF0aEVu dW0gbmV4dE9iamVjdF0pKQotICAgIHsKLSAgICAgIGlmIChbZmlsZU1hbmFnZXIgZmlsZUV4aXN0 c0F0UGF0aDogcmVzb3VyY2VQYXRoIGlzRGlyZWN0b3J5OiAmaXNEaXJdKQotICAgICAgICBpZiAo aXNEaXIpCi0gICAgICAgICAgewotICAgICAgICAgICAgaWYgKFtyZXNvdXJjZVBhdGhzIGxlbmd0 aF0gPiAwKQotICAgICAgICAgICAgICByZXNvdXJjZVBhdGhzCi0gICAgICAgICAgICAgICAgPSBb cmVzb3VyY2VQYXRocyBzdHJpbmdCeUFwcGVuZGluZ1N0cmluZzogcGF0aFNlcGFyYXRvcl07Ci0g ICAgICAgICAgICByZXNvdXJjZVBhdGhzCi0gICAgICAgICAgICAgID0gW3Jlc291cmNlUGF0aHMg c3RyaW5nQnlBcHBlbmRpbmdTdHJpbmc6IHJlc291cmNlUGF0aF07Ci0gICAgICAgICAgfQotICAg IH0KLSAgaWYgKFtyZXNvdXJjZVBhdGhzIGxlbmd0aF0gPiAwKSByZXR1cm4gW3Jlc291cmNlUGF0 aHMgVVRGOFN0cmluZ107CisjZW5kaWYKIAotICByZXR1cm4gTlVMTDsKKyAgcmV0dXJuIGVwYXRo OwogfQogCiAKLS0gCjIuMzAuMAoK --0000000000001ae9a905c552c4c8-- From unknown Sun Jun 22 04:29:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS) Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 Jun 2021 08:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48994 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Matthew Bauer Cc: 48994@debbugs.gnu.org, Eli Zaretskii , Andrea Corallo Received: via spool by 48994-submit@debbugs.gnu.org id=B48994.162435076326359 (code B ref 48994); Tue, 22 Jun 2021 08:33:02 +0000 Received: (at 48994) by debbugs.gnu.org; 22 Jun 2021 08:32:43 +0000 Received: from localhost ([127.0.0.1]:37707 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lvbpr-0006r5-4i for submit@debbugs.gnu.org; Tue, 22 Jun 2021 04:32:43 -0400 Received: from [217.169.17.33] (port=53711 helo=breton.holly.idiocy.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lvbpo-0006qp-Fd for 48994@debbugs.gnu.org; Tue, 22 Jun 2021 04:32:41 -0400 Received: by breton.holly.idiocy.org (Postfix, from userid 501) id C0699202CBB716; Tue, 22 Jun 2021 09:32:34 +0100 (BST) Date: Tue, 22 Jun 2021 09:32:34 +0100 From: Alan Third Message-ID: Mail-Followup-To: Alan Third , Matthew Bauer , Eli Zaretskii , 48994@debbugs.gnu.org, Andrea Corallo References: <83bl897kag.fsf@gnu.org> <8335tk7h32.fsf@gnu.org> <835yyg5k4p.fsf@gnu.org> <83fsxh1wdd.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Mon, Jun 21, 2021 at 10:55:40PM -0500, Matthew Bauer wrote: > > Matthew, could you please try the attached patch and see if it solves > > your problems (or makes them worse!)? > > That fixes the pr [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_NONE SPF: sender does not publish an SPF Record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) On Mon, Jun 21, 2021 at 10:55:40PM -0500, Matthew Bauer wrote: > > Matthew, could you please try the attached patch and see if it solves > > your problems (or makes them worse!)? > > That fixes the problem! I had to make a small change for it to work though > (needed to add prefix & exec_prefix to nextstep/Makefile.in). !? As far as I'm aware nextstep/Makefile shouldn't need to know about the prefix because it's not relevant to that type of install... What configure flags are you using? (They should be listed at the top of configure.log.) -- Alan Third From unknown Sun Jun 22 04:29:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS) Resent-From: Matthew Bauer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 Jun 2021 16:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48994 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Alan Third , Matthew Bauer , Eli Zaretskii , 48994@debbugs.gnu.org, Andrea Corallo Received: via spool by 48994-submit@debbugs.gnu.org id=B48994.1624380737688 (code B ref 48994); Tue, 22 Jun 2021 16:53:02 +0000 Received: (at 48994) by debbugs.gnu.org; 22 Jun 2021 16:52:17 +0000 Received: from localhost ([127.0.0.1]:39771 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lvjdI-0000B2-Qw for submit@debbugs.gnu.org; Tue, 22 Jun 2021 12:52:17 -0400 Received: from mail-ej1-f44.google.com ([209.85.218.44]:39928) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lvjdH-0000Am-I9 for 48994@debbugs.gnu.org; Tue, 22 Jun 2021 12:52:16 -0400 Received: by mail-ej1-f44.google.com with SMTP id l1so35624889ejb.6 for <48994@debbugs.gnu.org>; Tue, 22 Jun 2021 09:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=sd8WlmhOL0SYAgMd+SwXK+DjOUtHBFZ9qtOWTQ7ntPQ=; b=VlENgusHAex1+zb0DLufbKfiVniMkqYrV9QwnQH1bXDXnzFg1dlItPp1cc56EaNkn7 EAWhBQ/ewS377xbyW53PcAwuYclMR73jMlm0DCmOoERe18HbViyEEcQL2xTbjZPwsSwd kmRgqUpJtMx1owV+IvblskfOn0XKPfEBw09XR3U7+VZj2UJpRUpxu/6yeHATtM+pCBV9 DZ0NM+ylaIJCwxE3MGPPc9SrIK0LdKS6WJcFE8qe+jKLmwfAk5Apsppx4peMZCa+LmYn g/gWe0z+hUqL6V/90BxUd02wy4Tk+sl4DwHkPdo9MNh4wdlPJytPj6AM//zcb7etQy6u 4wQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=sd8WlmhOL0SYAgMd+SwXK+DjOUtHBFZ9qtOWTQ7ntPQ=; b=kTKZXcZqMRkrJmx3WOQYFaWlrxhpm3iBiJKknu00+OkF9Hr9GzkdMM+QVWGUYgGlTL FoG3xk0/Ky6E6mx0pbljK0xw6f9YUiNEYQudT1wmBJIFCRJfxyJy+7LCLSTLEZCYKCs1 6MuWyKEH4PU7EjPVEdSAXHFbOinty52wD+ZLuO/WFGskVmOKSQJcvsmRg0q29B4qh3PL a0sk6lVCUysrpBjfPhnnD9n3Bwj8Wg93DWCEzX90NpN9j9DySPCR2k/jjFZ6LJVlwWsy kBdpLFYmJB88qX0x1IO15leq/yNqYmYG7DeYXIki1HgnZ7sRrQe3Id89FlGw3CH2IP1F n45g== X-Gm-Message-State: AOAM533oXrwRptm4+J3chxr0/NNHb0gyxc/Wr3Z/s2z+XpdtXqBX1adU oxq/6iCXGGRrfKTkqqhYwijRpiYEuHVvZ7L8+jI= X-Google-Smtp-Source: ABdhPJy71JCaSn/PYXU/ySIdPsOVXzBMLXFQguNqFrPy47A1c6ngF0T50SSl7A/GFDS755K3ZDWrlJG3TWaSkbQBhJw= X-Received: by 2002:a17:906:a0a:: with SMTP id w10mr5032567ejf.416.1624380729451; Tue, 22 Jun 2021 09:52:09 -0700 (PDT) MIME-Version: 1.0 References: <83bl897kag.fsf@gnu.org> <8335tk7h32.fsf@gnu.org> <835yyg5k4p.fsf@gnu.org> <83fsxh1wdd.fsf@gnu.org> In-Reply-To: From: Matthew Bauer Date: Tue, 22 Jun 2021 11:51:57 -0500 Message-ID: Content-Type: multipart/alternative; boundary="0000000000005bea2205c55d9c57" X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --0000000000005bea2205c55d9c57 Content-Type: text/plain; charset="UTF-8" > !? > As far as I'm aware nextstep/Makefile shouldn't need to know about the > prefix because it's not relevant to that type of install... > What configure flags are you using? (They should be listed at the top > of configure.log.) There's probably a better to way to fix it - my familiarity with autoconf is not great. But in nextstep/Makefile we get this line: ns_applibexecdir = ${exec_prefix}/libexec > and exec_prefix undefined without defining prefix & exec_prefix. On Tue, Jun 22, 2021 at 3:32 AM Alan Third wrote: > On Mon, Jun 21, 2021 at 10:55:40PM -0500, Matthew Bauer wrote: > > > Matthew, could you please try the attached patch and see if it solves > > > your problems (or makes them worse!)? > > > > That fixes the problem! I had to make a small change for it to work > though > > (needed to add prefix & exec_prefix to nextstep/Makefile.in). > > !? > > As far as I'm aware nextstep/Makefile shouldn't need to know about the > prefix because it's not relevant to that type of install... > > What configure flags are you using? (They should be listed at the top > of configure.log.) > -- > Alan Third > --0000000000005bea2205c55d9c57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> !?

> As f= ar as I'm aware nextstep/Makefile shouldn't need to know about the<= br>> prefix because it's not relevant to that type of install...
=
> What configure flags are you using? (They should be listed at the = top
> of configure.log.)

There's probably a better to way to fix it = - my familiarity with autoconf is not great.

But i= n nextstep/Makefile we get this line:

= ns_applibexecdir =3D ${exec_prefix}/libexec

=
and exec_prefix undefined without defining prefix & exec_prefix.= =C2=A0

On Tue, Jun 22, 2021 at 3:32 AM Alan Third <alan@idiocy.org> wrote:
On Mon, Jun 21, 2021 at 10:55:40PM -0500, Matthew Bauer wrote:
> > Matthew, could you please try the attached patch and see if it so= lves
> > your problems (or makes them worse!)?
>
> That fixes the problem! I had to make a small change for it to work th= ough
> (needed to add prefix & exec_prefix to nextstep/Makefile.in).

!?

As far as I'm aware nextstep/Makefile shouldn't need to know about = the
prefix because it's not relevant to that type of install...

What configure flags are you using? (They should be listed at the top
of configure.log.)
--
Alan Third
--0000000000005bea2205c55d9c57-- From unknown Sun Jun 22 04:29:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS) Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 Jun 2021 17:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48994 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Matthew Bauer Cc: 48994@debbugs.gnu.org, Eli Zaretskii , Andrea Corallo Received: via spool by 48994-submit@debbugs.gnu.org id=B48994.16243812122076 (code B ref 48994); Tue, 22 Jun 2021 17:01:02 +0000 Received: (at 48994) by debbugs.gnu.org; 22 Jun 2021 17:00:12 +0000 Received: from localhost ([127.0.0.1]:39783 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lvjky-0000X5-6v for submit@debbugs.gnu.org; Tue, 22 Jun 2021 13:00:12 -0400 Received: from outbound.soverin.net ([116.202.126.228]:37769) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lvjkv-0000Nr-UN for 48994@debbugs.gnu.org; Tue, 22 Jun 2021 13:00:10 -0400 Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 640E094D; Tue, 22 Jun 2021 17:00:03 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1624381202; bh=mzKXI6F826JkUZFvoOb3Frz2eU7jUs7Si3Ppk35sX34=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Y6MNGsB+XP6F57ZdZ/L4DbmMxLb2auRImoKXljA8sLVp+EQqFF5Q0lg7xPZALP+8U spTnsLqg10e3A35Z3KABMGfskqQZDvkNyobSqkUOKvvYBNTW2v3GAVIemBlfU3opZh LBUv9VPkS4o6qwG0taYHw6sj3h8+UcN7oxb3sjIXNweKICIqttADhu2Pqyw7c7+E1y g35Y+gbx/J68YCNW0pKuxKBM3r8wTFM8UqFD09vXZWRrrbgtrDi4jXUp75+zjNwfoz 8Ic9QZd65r2wG6GlM6PZ0TH+wV1Vb9tteD0ep8wsNLXA9zYXWRTOrn0zClGdTt9zZv e0XAMXpD7fQUA== Received: from alan by faroe.holly.idiocy.org with local (Exim 4.94.2) (envelope-from ) id 1lvjkl-000eYS-4p; Tue, 22 Jun 2021 17:59:59 +0100 Date: Tue, 22 Jun 2021 17:59:59 +0100 From: Alan Third Message-ID: Mail-Followup-To: Alan Third , Matthew Bauer , Eli Zaretskii , 48994@debbugs.gnu.org, Andrea Corallo References: <8335tk7h32.fsf@gnu.org> <835yyg5k4p.fsf@gnu.org> <83fsxh1wdd.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On Tue, Jun 22, 2021 at 11:51:57AM -0500, Matthew Bauer wrote: > > !? > > > As far as I'm aware nextstep/Makefile shouldn't need to know about the > > prefix because it's not relevant to that type of install... > > > What configure flags are you using? (They should be listed at the top > > of configure.log.) > > There's probably a better to way to fix it - my familiarity with autoconf > is not great. > > But in nextstep/Makefile we get this line: > > ns_applibexecdir = ${exec_prefix}/libexec > > > > and exec_prefix undefined without defining prefix & exec_prefix. But you are building with the flag --disable-ns-self-contained? If so there's no need for nextstep/Makefile to do anything, so it shouldn't matter. I suppose we probably want to avoid generating that makefile, or not call it, or something... I'm not sure. -- Alan Third From unknown Sun Jun 22 04:29:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS) Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 Jun 2021 17:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48994 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Matthew Bauer , Eli Zaretskii , 48994@debbugs.gnu.org, Andrea Corallo Received: via spool by 48994-submit@debbugs.gnu.org id=B48994.162438270912426 (code B ref 48994); Tue, 22 Jun 2021 17:26:02 +0000 Received: (at 48994) by debbugs.gnu.org; 22 Jun 2021 17:25:09 +0000 Received: from localhost ([127.0.0.1]:39817 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lvk96-0003EL-0W for submit@debbugs.gnu.org; Tue, 22 Jun 2021 13:25:09 -0400 Received: from [217.169.17.33] (port=53877 helo=breton.holly.idiocy.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lvk91-0003Dc-I7 for 48994@debbugs.gnu.org; Tue, 22 Jun 2021 13:25:07 -0400 Received: by breton.holly.idiocy.org (Postfix, from userid 501) id 196FB202CBF519; Tue, 22 Jun 2021 18:24:56 +0100 (BST) Date: Tue, 22 Jun 2021 18:24:56 +0100 From: Alan Third Message-ID: Mail-Followup-To: Alan Third , Matthew Bauer , Eli Zaretskii , 48994@debbugs.gnu.org, Andrea Corallo References: <8335tk7h32.fsf@gnu.org> <835yyg5k4p.fsf@gnu.org> <83fsxh1wdd.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="gaHEXT62057NSZsL" Content-Disposition: inline In-Reply-To: X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Tue, Jun 22, 2021 at 05:59:59PM +0100, Alan Third wrote: > If so there's no need for nextstep/Makefile to do anything, so it > shouldn't matter. I suppose we probably want to avoid generating that [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 SPF_NONE SPF: sender does not publish an SPF Record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) --gaHEXT62057NSZsL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jun 22, 2021 at 05:59:59PM +0100, Alan Third wrote: > If so there's no need for nextstep/Makefile to do anything, so it > shouldn't matter. I suppose we probably want to avoid generating that > makefile, or not call it, or something... I'm not sure. Turns out there's another variable that should only be set when building the app. Please try the attached patch. -- Alan Third --gaHEXT62057NSZsL Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="v2-0001-Fix-NS-native-compilation-builds.patch" >From 7e4f2fe5470e6a6468c57f9167c23726ec636208 Mon Sep 17 00:00:00 2001 From: Alan Third Date: Wed, 16 Jun 2021 21:28:10 +0100 Subject: [PATCH v2] Fix NS native compilation builds * Makefile.in (ns_appdir): New variable. (.PHONY): Include new rule. (epaths-force-ns-self-contained): Remove the app bundle directory from all paths. * configure.ac (NS_SELF_CONTAINED): Set the default site-lisp directory instead of hard-coding it in the ObjC code, and use the new epaths generating make rule. * src/callproc.c (init_callproc_1): (init_callproc): Remove all the NS specific code as the special cases are now handled by decode_env_path. * src/emacs.c (load_pdump): (decode_env_path): Use ns_relocate to find the correct directory after relocation. * src/lread.c (load_path_default): Remove all the NS specific code as the special cases are now handled by decode_env_path. * src/nsterm.h: Update function definitions. * src/nsterm.m (ns_etc_directory): (ns_exec_path): (ns_load_path): Remove functions that are no longer needed. (ns_relocate): New function to calculate paths within the NS app bundle. --- Makefile.in | 17 +++++- configure.ac | 14 +++-- nextstep/Makefile.in | 10 ++-- src/Makefile.in | 2 +- src/callproc.c | 36 ++----------- src/emacs.c | 16 +++++- src/lread.c | 7 +-- src/nsterm.h | 4 +- src/nsterm.m | 125 ++++++++----------------------------------- 9 files changed, 73 insertions(+), 158 deletions(-) diff --git a/Makefile.in b/Makefile.in index 3facfa59a9..68fe7d781a 100644 --- a/Makefile.in +++ b/Makefile.in @@ -104,8 +104,10 @@ HAVE_NATIVE_COMP = # Location to install Emacs.app under GNUstep / macOS. # Later values may use these. +ns_appdir=@ns_appdir@ ns_appbindir=@ns_appbindir@ ns_appresdir=@ns_appresdir@ +ns_applibdir=@ns_applibdir@ # Either yes or no depending on whether this is a relocatable Emacs.app. ns_self_contained=@ns_self_contained@ @@ -328,12 +330,12 @@ BIN_DESTDIR= ELN_DESTDIR = $(DESTDIR)${libdir}/emacs/${version}/ else BIN_DESTDIR='${ns_appbindir}/' -ELN_DESTDIR = ${ns_appresdir}/ +ELN_DESTDIR = ${ns_applibdir}/emacs/${version}/ endif all: ${SUBDIR} info -.PHONY: all ${SUBDIR} blessmail epaths-force epaths-force-w32 etc-emacsver +.PHONY: all ${SUBDIR} blessmail epaths-force epaths-force-w32 epaths-force-ns-self-contained etc-emacsver # If configure were to just generate emacsver.tex from emacsver.tex.in # in the normal way, the timestamp of emacsver.tex would always be @@ -402,6 +404,17 @@ epaths-force-w32: -e "/^.*#/s|@SRC@|$${w32srcdir}|g") && \ ${srcdir}/build-aux/move-if-change epaths.h.$$$$ src/epaths.h +# A NextStep style app bundle is relocatable, so instead of +# hard-coding paths try to generate them at run-time. +# +# The paths are mostly the same, and the bundle paths are different +# between macOS and GNUstep, so just replace any references to the app +# bundle root itself with the relative path. +epaths-force-ns-self-contained: epaths-force + @(sed < ${srcdir}/src/epaths.h > epaths.h.$$$$ \ + -e 's;${ns_appdir}/;;') && \ + ${srcdir}/build-aux/move-if-change epaths.h.$$$$ src/epaths.h + lib-src src: $(NTDIR) lib src: lib-src diff --git a/configure.ac b/configure.ac index c828f8d782..bf03d10093 100644 --- a/configure.ac +++ b/configure.ac @@ -1891,10 +1891,10 @@ AC_DEFUN # so avoid NS_IMPL_COCOA if macuvs.h is absent. # Even a headless Emacs can build macuvs.h, so this should let you bootstrap. if test "${opsys}" = darwin && test -f "$srcdir/src/macuvs.h"; then - lispdirrel=Contents/Resources/lisp NS_IMPL_COCOA=yes ns_appdir=`pwd`/nextstep/Emacs.app ns_appbindir=${ns_appdir}/Contents/MacOS + ns_applibdir=${ns_appdir}/Contents/MacOS/lib ns_appresdir=${ns_appdir}/Contents/Resources ns_appsrc=Cocoa/Emacs.base ns_fontfile=macfont.o @@ -1952,6 +1952,7 @@ AC_DEFUN if test $NS_IMPL_GNUSTEP = yes; then ns_appdir=`pwd`/nextstep/Emacs.app ns_appbindir=${ns_appdir} + ns_applibdir=${ns_appdir}/lib ns_appresdir=${ns_appdir}/Resources ns_appsrc=GNUstep/Emacs.base ns_fontfile=nsfont.o @@ -2008,6 +2009,7 @@ AC_DEFUN window_system=nextstep # set up packaging dirs if test "${EN_NS_SELF_CONTAINED}" = yes; then + AC_DEFINE(NS_SELF_CONTAINED, 1, [Build an NS bundled app]) ns_self_contained=yes prefix=${ns_appresdir} exec_prefix=${ns_appbindir} @@ -2021,8 +2023,9 @@ AC_DEFUN infodir="\${ns_appresdir}/info" mandir="\${ns_appresdir}/man" lispdir="\${ns_appresdir}/lisp" - test "$locallisppathset" = no && locallisppath="" + test "$locallisppathset" = no && locallisppath="\${ns_appresdir}/site-lisp" INSTALL_ARCH_INDEP_EXTRA= + OTHER_FILES=ns-app fi NS_OBJC_OBJ="nsterm.o nsfns.o nsmenu.o nsselect.o nsimage.o $ns_fontfile" @@ -4071,7 +4074,6 @@ AC_DEFUN GNU_OBJC_CFLAGS="$GNU_OBJC_CFLAGS -fgnu-runtime -Wno-import -fconstant-string-class=NSConstantString -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 -DGSWARN -DGSDIAGNOSE" fi fi - OTHER_FILES=ns-app fi ### Use session management (-lSM -lICE) if available @@ -5409,6 +5411,7 @@ AC_DEFUN AC_SUBST(X_TOOLKIT_TYPE) AC_SUBST(ns_appdir) AC_SUBST(ns_appbindir) +AC_SUBST(ns_applibdir) AC_SUBST(ns_appresdir) AC_SUBST(ns_appsrc) AC_SUBST(GNU_OBJC_CFLAGS) @@ -6009,10 +6012,13 @@ m4_define AC_CONFIG_COMMANDS([src/epaths.h], [ if test "${opsys}" = "mingw32"; then ${MAKE-make} MAKEFILE_NAME=do-not-make-Makefile epaths-force-w32 +elif test "$EN_NS_SELF_CONTAINED" = "yes"; then + ${MAKE-make} MAKEFILE_NAME=do-not-make-Makefile epaths-force-ns-self-contained else ${MAKE-make} MAKEFILE_NAME=do-not-make-Makefile epaths-force fi || AC_MSG_ERROR(['src/epaths.h' could not be made.]) -], [GCC="$GCC" CPPFLAGS="$CPPFLAGS" opsys="$opsys"]) +], [GCC="$GCC" CPPFLAGS="$CPPFLAGS" opsys="$opsys" + EN_NS_SELF_CONTAINED="$EN_NS_SELF_CONTAINED"]) dnl NB we have to cheat and use the ac_... version because abs_top_srcdir dnl is not yet set, sigh. Or we could use ../$srcdir/src/.gdbinit, diff --git a/nextstep/Makefile.in b/nextstep/Makefile.in index 3168fee76c..c0beb454d1 100644 --- a/nextstep/Makefile.in +++ b/nextstep/Makefile.in @@ -38,13 +38,14 @@ ns_appdir = ns_appbindir = @ns_appbindir@ ## GNUstep/Emacs.base or Cocoa/Emacs.base. ns_appsrc = @ns_appsrc@ +ns_applibexecdir = @libexecdir@ ## GNUstep: GNUstep/Emacs.base/Resources/Info-gnustep.plist ## macOS: Cocoa/Emacs.base/Contents/Info.plist ns_check_file = @ns_appdir@/@ns_check_file@ .PHONY: all -all: ${ns_appdir} ${ns_appbindir}/Emacs ${ns_appbindir}/Emacs.pdmp +all: ${ns_appdir} ${ns_appbindir}/Emacs ${ns_applibexecdir}/Emacs.pdmp ${ns_check_file} ${ns_appdir}: ${srcdir}/${ns_appsrc} ${ns_appsrc} rm -rf ${ns_appdir} @@ -63,8 +64,8 @@ ${ns_appbindir}/Emacs: ${MKDIR_P} ${ns_appbindir} cp -f ../src/emacs${EXEEXT} $@ -${ns_appbindir}/Emacs.pdmp: ${ns_appdir} ${ns_check_file} ../src/emacs${EXEEXT}.pdmp - ${MKDIR_P} ${ns_appbindir} +${ns_applibexecdir}/Emacs.pdmp: ${ns_appdir} ${ns_check_file} ../src/emacs${EXEEXT}.pdmp + ${MKDIR_P} ${ns_applibexecdir} cp -f ../src/emacs${EXEEXT}.pdmp $@ .PHONY: FORCE @@ -85,9 +86,8 @@ links: ln -s $(top_srcdir_abs)/info ${ns_appdir}/Contents/Resources ${MKDIR_P} ${ns_appbindir} ln -s $(abs_top_builddir)/src/emacs${EXEEXT} ${ns_appbindir}/Emacs - ln -s $(abs_top_builddir)/src/emacs${EXEEXT}.pdmp ${ns_appbindir}/Emacs.pdmp ln -s $(abs_top_builddir)/lib-src ${ns_appbindir}/bin - ln -s $(abs_top_builddir)/lib-src ${ns_appbindir}/libexec + ln -s $(abs_top_builddir)/lib-src ${ns_applibexecdir} ${MKDIR_P} ${ns_appdir}/Contents/Resources/etc for f in $(shell cd $(top_srcdir_abs)/etc; ls); do ln -s $(top_srcdir_abs)/etc/$$f ${ns_appdir}/Contents/Resources/etc; done ln -s $(abs_top_builddir)/etc/DOC ${ns_appdir}/Contents/Resources/etc diff --git a/src/Makefile.in b/src/Makefile.in index 79cddb35b5..22c7aeed5c 100644 --- a/src/Makefile.in +++ b/src/Makefile.in @@ -55,7 +55,7 @@ lwlibdir = # Configuration files for .o files to depend on. config_h = config.h $(srcdir)/conf_post.h -## ns-app if HAVE_NS, else empty. +## ns-app if NS self contained app, else empty. OTHER_FILES = @OTHER_FILES@ ## Flags to pass for profiling builds diff --git a/src/callproc.c b/src/callproc.c index e44e243680..aabc39313b 100644 --- a/src/callproc.c +++ b/src/callproc.c @@ -1661,32 +1661,15 @@ make_environment_block (Lisp_Object current_dir) void init_callproc_1 (void) { -#ifdef HAVE_NS - const char *etc_dir = ns_etc_directory (); - const char *path_exec = ns_exec_path (); -#endif - - Vdata_directory = decode_env_path ("EMACSDATA", -#ifdef HAVE_NS - etc_dir ? etc_dir : -#endif - PATH_DATA, 0); + Vdata_directory = decode_env_path ("EMACSDATA", PATH_DATA, 0); Vdata_directory = Ffile_name_as_directory (Fcar (Vdata_directory)); - Vdoc_directory = decode_env_path ("EMACSDOC", -#ifdef HAVE_NS - etc_dir ? etc_dir : -#endif - PATH_DOC, 0); + Vdoc_directory = decode_env_path ("EMACSDOC", PATH_DOC, 0); Vdoc_directory = Ffile_name_as_directory (Fcar (Vdoc_directory)); /* Check the EMACSPATH environment variable, defaulting to the PATH_EXEC path from epaths.h. */ - Vexec_path = decode_env_path ("EMACSPATH", -#ifdef HAVE_NS - path_exec ? path_exec : -#endif - PATH_EXEC, 0); + Vexec_path = decode_env_path ("EMACSPATH", PATH_EXEC, 0); Vexec_directory = Ffile_name_as_directory (Fcar (Vexec_path)); /* FIXME? For ns, path_exec should go at the front? */ Vexec_path = nconc2 (decode_env_path ("PATH", "", 0), Vexec_path); @@ -1701,10 +1684,6 @@ init_callproc (void) char *sh; Lisp_Object tempdir; -#ifdef HAVE_NS - if (data_dir == 0) - data_dir = ns_etc_directory () != 0; -#endif if (!NILP (Vinstallation_directory)) { @@ -1716,15 +1695,8 @@ init_callproc (void) /* MSDOS uses wrapped binaries, so don't do this. */ if (NILP (Fmember (tem, Vexec_path))) { -#ifdef HAVE_NS - const char *path_exec = ns_exec_path (); -#endif /* Running uninstalled, so default to tem rather than PATH_EXEC. */ - Vexec_path = decode_env_path ("EMACSPATH", -#ifdef HAVE_NS - path_exec ? path_exec : -#endif - SSDATA (tem), 0); + Vexec_path = decode_env_path ("EMACSPATH", SSDATA (tem), 0); Vexec_path = nconc2 (decode_env_path ("PATH", "", 0), Vexec_path); } diff --git a/src/emacs.c b/src/emacs.c index 60a57a693c..b7982ece64 100644 --- a/src/emacs.c +++ b/src/emacs.c @@ -835,7 +835,13 @@ load_pdump (int argc, char **argv) NULL #endif ; - const char *argv0_base = "emacs"; + const char *argv0_base = +#ifdef NS_SELF_CONTAINED + "Emacs" +#else + "emacs" +#endif + ; /* TODO: maybe more thoroughly scrub process environment in order to make this use case (loading a dump file in an unexeced emacs) @@ -912,6 +918,8 @@ load_pdump (int argc, char **argv) /* On MS-Windows, PATH_EXEC normally starts with a literal "%emacs_dir%", so it will never work without some tweaking. */ path_exec = w32_relocate (path_exec); +#elif defined (HAVE_NS) + path_exec = ns_relocate (path_exec); #endif /* Look for "emacs.pdmp" in PATH_EXEC. We hardcode "emacs" in @@ -929,6 +937,7 @@ load_pdump (int argc, char **argv) } sprintf (dump_file, "%s%c%s%s", path_exec, DIRECTORY_SEP, argv0_base, suffix); +#if !defined (NS_SELF_CONTAINED) /* Assume the Emacs binary lives in a sibling directory as set up by the default installation configuration. */ const char *go_up = "../../../../bin/"; @@ -943,6 +952,7 @@ load_pdump (int argc, char **argv) sprintf (emacs_executable, "%s%c%s%s%s", path_exec, DIRECTORY_SEP, go_up, argv0_base, strip_suffix ? strip_suffix : ""); +#endif result = pdumper_load (dump_file, emacs_executable); if (result == PDUMPER_LOAD_FILE_NOT_FOUND) @@ -2960,7 +2970,11 @@ decode_env_path (const char *evarname, const char *defalt, bool empty) path = 0; if (!path) { +#ifdef NS_SELF_CONTAINED + path = ns_relocate (defalt); +#else path = defalt; +#endif #ifdef WINDOWSNT defaulted = 1; #endif diff --git a/src/lread.c b/src/lread.c index 0b33fd0f25..4617ffd626 100644 --- a/src/lread.c +++ b/src/lread.c @@ -4769,14 +4769,9 @@ load_path_default (void) return decode_env_path (0, PATH_DUMPLOADSEARCH, 0); Lisp_Object lpath = Qnil; - const char *normal = PATH_LOADSEARCH; const char *loadpath = NULL; -#ifdef HAVE_NS - loadpath = ns_load_path (); -#endif - - lpath = decode_env_path (0, loadpath ? loadpath : normal, 0); + lpath = decode_env_path (0, PATH_LOADSEARCH, 0); if (!NILP (Vinstallation_directory)) { diff --git a/src/nsterm.h b/src/nsterm.h index e7ea907569..139c37a29e 100644 --- a/src/nsterm.h +++ b/src/nsterm.h @@ -1186,9 +1186,7 @@ #define NSAPP_DATA2_RUNASSCRIPT 10 #define NSAPP_DATA2_RUNFILEDIALOG 11 extern void ns_run_file_dialog (void); -extern const char *ns_etc_directory (void); -extern const char *ns_exec_path (void); -extern const char *ns_load_path (void); +extern const char *ns_relocate (const char *epath); extern void syms_of_nsterm (void); extern void syms_of_nsfns (void); extern void syms_of_nsmenu (void); diff --git a/src/nsterm.m b/src/nsterm.m index 838c14d5ab..7b0b169e10 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -499,118 +499,35 @@ - (NSColor *)colorUsingDefaultColorSpace const char * -ns_etc_directory (void) -/* If running as a self-contained app bundle, return as a string the - filename of the etc directory, if present; else nil. */ -{ - NSBundle *bundle = [NSBundle mainBundle]; - NSString *resourceDir = [bundle resourcePath]; - NSString *resourcePath; - NSFileManager *fileManager = [NSFileManager defaultManager]; - BOOL isDir; +ns_relocate (const char *epath) +/* If we're running in a self-contained app bundle some hard-coded + paths are relative to the root of the bundle, so work out the full + path. - resourcePath = [resourceDir stringByAppendingPathComponent: @"etc"]; - if ([fileManager fileExistsAtPath: resourcePath isDirectory: &isDir]) - { - if (isDir) return [resourcePath UTF8String]; - } - return NULL; -} - - -const char * -ns_exec_path (void) -/* If running as a self-contained app bundle, return as a path string - the filenames of the libexec and bin directories, ie libexec:bin. - Otherwise, return nil. - Normally, Emacs does not add its own bin/ directory to the PATH. - However, a self-contained NS build has a different layout, with - bin/ and libexec/ subdirectories in the directory that contains - Emacs.app itself. - We put libexec first, because init_callproc_1 uses the first - element to initialize exec-directory. An alternative would be - for init_callproc to check for invocation-directory/libexec. -*/ + FIXME: I think this should be able to handle cases where multiple + directories are separated by colons. */ { +#ifdef NS_SELF_CONTAINED NSBundle *bundle = [NSBundle mainBundle]; - NSString *resourceDir = [bundle resourcePath]; - NSString *binDir = [bundle bundlePath]; - NSString *resourcePath, *resourcePaths; - NSRange range; - NSString *pathSeparator = [NSString stringWithFormat: @"%c", SEPCHAR]; + NSString *root = [bundle bundlePath]; + NSString *original = [NSString stringWithUTF8String:epath]; + NSString *fixedPath = [NSString pathWithComponents:@[root, original]]; NSFileManager *fileManager = [NSFileManager defaultManager]; - NSArray *paths; - NSEnumerator *pathEnum; - BOOL isDir; - range = [resourceDir rangeOfString: @"Contents"]; - if (range.location != NSNotFound) - { - binDir = [binDir stringByAppendingPathComponent: @"Contents"]; -#ifdef NS_IMPL_COCOA - binDir = [binDir stringByAppendingPathComponent: @"MacOS"]; -#endif - } + if (![original isAbsolutePath] + && [fileManager fileExistsAtPath:fixedPath isDirectory:nil]) + return [fixedPath UTF8String]; - paths = [binDir stringsByAppendingPaths: - [NSArray arrayWithObjects: @"libexec", @"bin", nil]]; - pathEnum = [paths objectEnumerator]; - resourcePaths = @""; + /* If we reach here either the path is absolute and therefore we + don't need to complete it, or we're unable to relocate the + file/directory. If it's the latter it may be because the user is + trying to use a bundled app as though it's a Unix style install + and we have no way to guess what was intended, so return the + original string unaltered. */ - while ((resourcePath = [pathEnum nextObject])) - { - if ([fileManager fileExistsAtPath: resourcePath isDirectory: &isDir]) - if (isDir) - { - if ([resourcePaths length] > 0) - resourcePaths - = [resourcePaths stringByAppendingString: pathSeparator]; - resourcePaths - = [resourcePaths stringByAppendingString: resourcePath]; - } - } - if ([resourcePaths length] > 0) return [resourcePaths UTF8String]; - - return NULL; -} - - -const char * -ns_load_path (void) -/* If running as a self-contained app bundle, return as a path string - the filenames of the site-lisp and lisp directories. - Ie, site-lisp:lisp. Otherwise, return nil. */ -{ - NSBundle *bundle = [NSBundle mainBundle]; - NSString *resourceDir = [bundle resourcePath]; - NSString *resourcePath, *resourcePaths; - NSString *pathSeparator = [NSString stringWithFormat: @"%c", SEPCHAR]; - NSFileManager *fileManager = [NSFileManager defaultManager]; - BOOL isDir; - NSArray *paths = [resourceDir stringsByAppendingPaths: - [NSArray arrayWithObjects: - @"site-lisp", @"lisp", nil]]; - NSEnumerator *pathEnum = [paths objectEnumerator]; - resourcePaths = @""; - - /* Hack to skip site-lisp. */ - if (no_site_lisp) resourcePath = [pathEnum nextObject]; - - while ((resourcePath = [pathEnum nextObject])) - { - if ([fileManager fileExistsAtPath: resourcePath isDirectory: &isDir]) - if (isDir) - { - if ([resourcePaths length] > 0) - resourcePaths - = [resourcePaths stringByAppendingString: pathSeparator]; - resourcePaths - = [resourcePaths stringByAppendingString: resourcePath]; - } - } - if ([resourcePaths length] > 0) return [resourcePaths UTF8String]; +#endif - return NULL; + return epath; } -- 2.29.2 --gaHEXT62057NSZsL-- From unknown Sun Jun 22 04:29:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS) Resent-From: Matthew Bauer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 Jun 2021 23:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48994 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Alan Third , Matthew Bauer , Eli Zaretskii , 48994@debbugs.gnu.org, Andrea Corallo Received: via spool by 48994-submit@debbugs.gnu.org id=B48994.162440290428663 (code B ref 48994); Tue, 22 Jun 2021 23:02:02 +0000 Received: (at 48994) by debbugs.gnu.org; 22 Jun 2021 23:01:44 +0000 Received: from localhost ([127.0.0.1]:40057 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lvpOq-0007SE-6Q for submit@debbugs.gnu.org; Tue, 22 Jun 2021 19:01:44 -0400 Received: from mail-ej1-f54.google.com ([209.85.218.54]:35754) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lvpOo-0007S1-I2 for 48994@debbugs.gnu.org; Tue, 22 Jun 2021 19:01:42 -0400 Received: by mail-ej1-f54.google.com with SMTP id gn32so943000ejc.2 for <48994@debbugs.gnu.org>; Tue, 22 Jun 2021 16:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=U8KiWZIZj6P6BOCu7X2I8UkoW8Y85GYEKVhuwGkP4iA=; b=IKYifC17mVNyvjpHJExc9bfmG32A2Bqs8jcLTr6lTRDu8dpLEPNyJA4URU1aPBbPXo 71KUobLNvI2DaM/Han5PwxIe1XkLurrg6mu14eYA9UsDGXX9d/piuuKkWr8s5o1Bw1eN +1DJKai31e+5HXIOBoF7LkgZYIFlMKp6sDSE3spQACTxHm/sLPABcNrAb7CVpGei3jRD wvB34+S/92PA+kh4CrfFLpypYhXphCwFJQ7vTQTrIKkRRuEHqqKk7OH6vkLdQ6K8Zp03 C3JUSC7MZCpCiuvuuJBOWPIW9KLTNKerzVx8kvFYuatM7mUyyNVBIgy4y/x6351XNWX+ yMQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=U8KiWZIZj6P6BOCu7X2I8UkoW8Y85GYEKVhuwGkP4iA=; b=McZM46+RFMYe3SJpweinzCaEKvDgrJQ/giGHhDWRZxbNosw56iTV7NGdqYIIwkgFKD ERiJwGvTNDPsvm5pvkDZCFaxZHvncO5V3FIjzJ532udu5n3WDsjofT0kPYDHNry3FvFW 8s4ojOJ65uSV7cqdzN/eKxJTrCqIpkmD+IyNQteAFIvAaFfSYe1tOocMcP6jlQ2qoqvW BYu9rdOR8nhSj4nsv5ui7JImDYcK59Rcv7vCbXcqz3E9X2TM/uYjkTPglqpH/egVNbti ftAK7CnNdGDKFAxLf3dxu1qDa3r0LcWo9hAR+x2gAAAKFpllDwaaFynvYTdfpV1EBZ1W rYCw== X-Gm-Message-State: AOAM532/Cbtuv5J3cYDgl6Hr8Nw4US8lRKQ2FUp9C6B3Yp8wZuqkFgEN qWgNG9r3lfrLKxzJmfJ0lx7FH2ioN0t9bi37ru4= X-Google-Smtp-Source: ABdhPJzAUIDC0dfgreDg1815fV7BgqJWQYIoxViad+VtgaLFg0PWv9CcPFVMOJqV9R1VIDZwF8D0vL3au5IgSgoWXjQ= X-Received: by 2002:a17:907:20da:: with SMTP id qq26mr6398177ejb.42.1624402896640; Tue, 22 Jun 2021 16:01:36 -0700 (PDT) MIME-Version: 1.0 References: <8335tk7h32.fsf@gnu.org> <835yyg5k4p.fsf@gnu.org> <83fsxh1wdd.fsf@gnu.org> In-Reply-To: From: Matthew Bauer Date: Tue, 22 Jun 2021 18:01:25 -0500 Message-ID: Content-Type: multipart/alternative; boundary="000000000000a0604d05c562c53e" X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --000000000000a0604d05c562c53e Content-Type: text/plain; charset="UTF-8" > Turns out there's another variable that should only be set when > building the app. > Please try the attached patch. That works for me ! So previously the nextstep/Emacs.app was getting generated even with --disable-ns-self-contained. I think that's fine to not build in this case - in fact it duplicates the Emacs executable - but just a note that it kind of changes things for packages. I have a fix for Nixpkgs (which previously installed nexstep/Emacs.app), but I think homebrew-emacs-plus would also be effected: https://github.com/d12frosted/homebrew-emacs-plus On Tue, Jun 22, 2021 at 12:24 PM Alan Third wrote: > On Tue, Jun 22, 2021 at 05:59:59PM +0100, Alan Third wrote: > > If so there's no need for nextstep/Makefile to do anything, so it > > shouldn't matter. I suppose we probably want to avoid generating that > > makefile, or not call it, or something... I'm not sure. > > Turns out there's another variable that should only be set when > building the app. > > Please try the attached patch. > -- > Alan Third > --000000000000a0604d05c562c53e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Tu= rns out there's another variable that should only be set when
> b= uilding the app.

> Please try the attached patch.

That works for me = !

So previously the nextstep/Emacs.app was getting= generated even with=C2=A0--disable-ns-self-contained. I think that's f= ine to not build in this=C2=A0case - in fact it duplicates the Emacs execut= able - but just a note that it kind of changes things for packages. I have = a fix for Nixpkgs (which previously installed nexstep/Emacs.app), but I thi= nk homebrew-emacs-plus would also be effected:


On Tue, Jun 22, = 2021 at 12:24 PM Alan Third <alan@idi= ocy.org> wrote:
On Tue, Jun 22, 2021 at 05= :59:59PM +0100, Alan Third wrote:
> If so there's no need for nextstep/Makefile to do anything, so it<= br> > shouldn't matter. I suppose we probably want to avoid generating t= hat
> makefile, or not call it, or something... I'm not sure.

Turns out there's another variable that should only be set when
building the app.

Please try the attached patch.
--
Alan Third
--000000000000a0604d05c562c53e-- From unknown Sun Jun 22 04:29:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS) Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Jun 2021 16:00:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48994 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Matthew Bauer Cc: 48994@debbugs.gnu.org, Eli Zaretskii , Andrea Corallo Received: via spool by 48994-submit@debbugs.gnu.org id=B48994.162446398824613 (code B ref 48994); Wed, 23 Jun 2021 16:00:03 +0000 Received: (at 48994) by debbugs.gnu.org; 23 Jun 2021 15:59:48 +0000 Received: from localhost ([127.0.0.1]:41746 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lw5I3-0006Ou-Nj for submit@debbugs.gnu.org; Wed, 23 Jun 2021 11:59:48 -0400 Received: from outbound.soverin.net ([116.202.126.228]:45305) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lw5Hy-0006Oe-Jp for 48994@debbugs.gnu.org; Wed, 23 Jun 2021 11:59:46 -0400 Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 61BE3963; Wed, 23 Jun 2021 15:59:36 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1624463975; bh=JD/oV8rFoGKOGeh6TXph8hnwU3DJObnQ9Ug0X8jjYaQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KE11jv49JOJepiZVraIwbTQVOS5SpPui7HLfX07jGJV1wzbWl+1yqXpvb4cpVu9yk spsBAkY/jxUL5pJ9R9AkIFEHppwlV/PifO2DtueMVi5Myf9WcSiJX2OeOlYZ6PBVLs 9U8wq6shRtcSIsETQYACudBKmXM9Us16puMUcddjGMTaj+/MAK10JR3JBBIyDT+rNz WOZBDHOsDTAF0MLC5HAHEr201/e1yzbpzMQ++OvvMe9SomY0KBMAw1lNMOhDHqkYPG XH2rrHosEuaAXm+Ndgf9tgCP3UqXMyUn3EBQuv77Lmn4wkrBsiJyYkyB8/wao5tdhI qstdbg5r06q2A== Received: from alan by faroe.holly.idiocy.org with local (Exim 4.94.2) (envelope-from ) id 1lw5Hn-0017TZ-Vb; Wed, 23 Jun 2021 16:59:32 +0100 Date: Wed, 23 Jun 2021 16:59:31 +0100 From: Alan Third Message-ID: Mail-Followup-To: Alan Third , Matthew Bauer , Eli Zaretskii , 48994@debbugs.gnu.org, Andrea Corallo References: <835yyg5k4p.fsf@gnu.org> <83fsxh1wdd.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="lW+ZmI3DrBy7gYMU" Content-Disposition: inline In-Reply-To: X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --lW+ZmI3DrBy7gYMU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jun 22, 2021 at 06:01:25PM -0500, Matthew Bauer wrote: > > Turns out there's another variable that should only be set when > > building the app. > > > Please try the attached patch. > > That works for me ! > > So previously the nextstep/Emacs.app was getting generated even > with --disable-ns-self-contained. I think that's fine to not build in > this case - in fact it duplicates the Emacs executable - but just a note > that it kind of changes things for packages. I have a fix for Nixpkgs > (which previously installed nexstep/Emacs.app), but I think > homebrew-emacs-plus would also be effected: > > https://github.com/d12frosted/homebrew-emacs-plus This sounds like madness to me, but I see it's a supported configuration mentioned in our install files. So, attempt three attached! -- Alan Third --lW+ZmI3DrBy7gYMU Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v3-0001-Fix-NS-native-compilation-builds.patch" >From 230988308c157ff07ae9b7d2ce51ba1913c81fe2 Mon Sep 17 00:00:00 2001 From: Alan Third Date: Wed, 16 Jun 2021 21:28:10 +0100 Subject: [PATCH v3] Fix NS native compilation builds * Makefile.in (ns_applibexecdir): (ns_applibdir): (ns_appdir): New variables. (.PHONY): Include new rule. (epaths-force-ns-self-contained): Remove the app bundle directory from all paths. * configure.ac (NS_SELF_CONTAINED): Set the default site-lisp directory instead of hard-coding it in the ObjC code, and use the new epaths generating make rule. * src/callproc.c (init_callproc_1): (init_callproc): Remove all the NS specific code as the special cases are now handled by decode_env_path. * src/emacs.c (load_pdump): (decode_env_path): Use ns_relocate to find the correct directory after relocation. * src/lread.c (load_path_default): Remove all the NS specific code as the special cases are now handled by decode_env_path. * src/nsterm.h: Update function definitions. * src/nsterm.m (ns_etc_directory): (ns_exec_path): (ns_load_path): Remove functions that are no longer needed. (ns_relocate): New function to calculate paths within the NS app bundle. * nextstep/Makefile.in (ns_applibexecdir): New variable, and update anything relying on the libexec location. --- Makefile.in | 18 ++++++- configure.ac | 19 +++++-- nextstep/Makefile.in | 10 ++-- src/Makefile.in | 2 +- src/callproc.c | 36 ++----------- src/emacs.c | 16 +++++- src/lread.c | 7 +-- src/nsterm.h | 4 +- src/nsterm.m | 125 ++++++++----------------------------------- 9 files changed, 78 insertions(+), 159 deletions(-) diff --git a/Makefile.in b/Makefile.in index b750288023..420cb544a4 100644 --- a/Makefile.in +++ b/Makefile.in @@ -106,8 +106,11 @@ USE_STARTUP_NOTIFICATION = # Location to install Emacs.app under GNUstep / macOS. # Later values may use these. +ns_appdir=@ns_appdir@ ns_appbindir=@ns_appbindir@ +ns_applibexecdir=@ns_applibexecdir@ ns_appresdir=@ns_appresdir@ +ns_applibdir=@ns_applibdir@ # Either yes or no depending on whether this is a relocatable Emacs.app. ns_self_contained=@ns_self_contained@ @@ -330,12 +333,12 @@ BIN_DESTDIR= ELN_DESTDIR = $(DESTDIR)${libdir}/emacs/${version}/ else BIN_DESTDIR='${ns_appbindir}/' -ELN_DESTDIR = ${ns_appresdir}/ +ELN_DESTDIR = ${ns_applibdir}/emacs/${version}/ endif all: ${SUBDIR} info -.PHONY: all ${SUBDIR} blessmail epaths-force epaths-force-w32 etc-emacsver +.PHONY: all ${SUBDIR} blessmail epaths-force epaths-force-w32 epaths-force-ns-self-contained etc-emacsver # If configure were to just generate emacsver.tex from emacsver.tex.in # in the normal way, the timestamp of emacsver.tex would always be @@ -404,6 +407,17 @@ epaths-force-w32: -e "/^.*#/s|@SRC@|$${w32srcdir}|g") && \ ${srcdir}/build-aux/move-if-change epaths.h.$$$$ src/epaths.h +# A NextStep style app bundle is relocatable, so instead of +# hard-coding paths try to generate them at run-time. +# +# The paths are mostly the same, and the bundle paths are different +# between macOS and GNUstep, so just replace any references to the app +# bundle root itself with the relative path. +epaths-force-ns-self-contained: epaths-force + @(sed < ${srcdir}/src/epaths.h > epaths.h.$$$$ \ + -e 's;${ns_appdir}/;;') && \ + ${srcdir}/build-aux/move-if-change epaths.h.$$$$ src/epaths.h + lib-src src: $(NTDIR) lib src: lib-src diff --git a/configure.ac b/configure.ac index 830f33844b..92527056b9 100644 --- a/configure.ac +++ b/configure.ac @@ -1891,10 +1891,11 @@ AC_DEFUN # so avoid NS_IMPL_COCOA if macuvs.h is absent. # Even a headless Emacs can build macuvs.h, so this should let you bootstrap. if test "${opsys}" = darwin && test -f "$srcdir/src/macuvs.h"; then - lispdirrel=Contents/Resources/lisp NS_IMPL_COCOA=yes ns_appdir=`pwd`/nextstep/Emacs.app ns_appbindir=${ns_appdir}/Contents/MacOS + ns_applibexecdir=${ns_appdir}/Contents/MacOS/libexec + ns_applibdir=${ns_appdir}/Contents/MacOS/lib ns_appresdir=${ns_appdir}/Contents/Resources ns_appsrc=Cocoa/Emacs.base ns_fontfile=macfont.o @@ -1952,6 +1953,8 @@ AC_DEFUN if test $NS_IMPL_GNUSTEP = yes; then ns_appdir=`pwd`/nextstep/Emacs.app ns_appbindir=${ns_appdir} + ns_applibexecdir=${ns_appdir}/libexec + ns_applibdir=${ns_appdir}/lib ns_appresdir=${ns_appdir}/Resources ns_appsrc=GNUstep/Emacs.base ns_fontfile=nsfont.o @@ -2008,12 +2011,13 @@ AC_DEFUN window_system=nextstep # set up packaging dirs if test "${EN_NS_SELF_CONTAINED}" = yes; then + AC_DEFINE(NS_SELF_CONTAINED, 1, [Build an NS bundled app]) ns_self_contained=yes prefix=${ns_appresdir} exec_prefix=${ns_appbindir} dnl This one isn't really used, only archlibdir is. - libexecdir="\${ns_appbindir}/libexec" - archlibdir="\${ns_appbindir}/libexec" + libexecdir="\${ns_applibexecdir}" + archlibdir="\${ns_applibexecdir}" etcdocdir="\${ns_appresdir}/etc" etcdir="\${ns_appresdir}/etc" dnl FIXME maybe set datarootdir instead. @@ -2021,7 +2025,7 @@ AC_DEFUN infodir="\${ns_appresdir}/info" mandir="\${ns_appresdir}/man" lispdir="\${ns_appresdir}/lisp" - test "$locallisppathset" = no && locallisppath="" + test "$locallisppathset" = no && locallisppath="\${ns_appresdir}/site-lisp" INSTALL_ARCH_INDEP_EXTRA= fi @@ -5414,6 +5418,8 @@ AC_DEFUN AC_SUBST(X_TOOLKIT_TYPE) AC_SUBST(ns_appdir) AC_SUBST(ns_appbindir) +AC_SUBST(ns_applibexecdir) +AC_SUBST(ns_applibdir) AC_SUBST(ns_appresdir) AC_SUBST(ns_appsrc) AC_SUBST(GNU_OBJC_CFLAGS) @@ -6014,10 +6020,13 @@ m4_define AC_CONFIG_COMMANDS([src/epaths.h], [ if test "${opsys}" = "mingw32"; then ${MAKE-make} MAKEFILE_NAME=do-not-make-Makefile epaths-force-w32 +elif test "$EN_NS_SELF_CONTAINED" = "yes"; then + ${MAKE-make} MAKEFILE_NAME=do-not-make-Makefile epaths-force-ns-self-contained else ${MAKE-make} MAKEFILE_NAME=do-not-make-Makefile epaths-force fi || AC_MSG_ERROR(['src/epaths.h' could not be made.]) -], [GCC="$GCC" CPPFLAGS="$CPPFLAGS" opsys="$opsys"]) +], [GCC="$GCC" CPPFLAGS="$CPPFLAGS" opsys="$opsys" + EN_NS_SELF_CONTAINED="$EN_NS_SELF_CONTAINED"]) dnl NB we have to cheat and use the ac_... version because abs_top_srcdir dnl is not yet set, sigh. Or we could use ../$srcdir/src/.gdbinit, diff --git a/nextstep/Makefile.in b/nextstep/Makefile.in index 3168fee76c..f556663510 100644 --- a/nextstep/Makefile.in +++ b/nextstep/Makefile.in @@ -36,6 +36,7 @@ MKDIR_P = ns_appdir = @ns_appdir@ ## GNUstep: ns_appdir; macOS: ns_appdir/Contents/MacOS ns_appbindir = @ns_appbindir@ +ns_applibexecdir = @ns_applibexecdir@ ## GNUstep/Emacs.base or Cocoa/Emacs.base. ns_appsrc = @ns_appsrc@ ## GNUstep: GNUstep/Emacs.base/Resources/Info-gnustep.plist @@ -44,7 +45,7 @@ ns_check_file = .PHONY: all -all: ${ns_appdir} ${ns_appbindir}/Emacs ${ns_appbindir}/Emacs.pdmp +all: ${ns_appdir} ${ns_appbindir}/Emacs ${ns_applibexecdir}/Emacs.pdmp ${ns_check_file} ${ns_appdir}: ${srcdir}/${ns_appsrc} ${ns_appsrc} rm -rf ${ns_appdir} @@ -63,8 +64,8 @@ ${ns_appbindir}/Emacs: ${MKDIR_P} ${ns_appbindir} cp -f ../src/emacs${EXEEXT} $@ -${ns_appbindir}/Emacs.pdmp: ${ns_appdir} ${ns_check_file} ../src/emacs${EXEEXT}.pdmp - ${MKDIR_P} ${ns_appbindir} +${ns_applibexecdir}/Emacs.pdmp: ${ns_appdir} ${ns_check_file} ../src/emacs${EXEEXT}.pdmp + ${MKDIR_P} ${ns_applibexecdir} cp -f ../src/emacs${EXEEXT}.pdmp $@ .PHONY: FORCE @@ -85,9 +86,8 @@ links: ln -s $(top_srcdir_abs)/info ${ns_appdir}/Contents/Resources ${MKDIR_P} ${ns_appbindir} ln -s $(abs_top_builddir)/src/emacs${EXEEXT} ${ns_appbindir}/Emacs - ln -s $(abs_top_builddir)/src/emacs${EXEEXT}.pdmp ${ns_appbindir}/Emacs.pdmp ln -s $(abs_top_builddir)/lib-src ${ns_appbindir}/bin - ln -s $(abs_top_builddir)/lib-src ${ns_appbindir}/libexec + ln -s $(abs_top_builddir)/lib-src ${ns_applibexecdir} ${MKDIR_P} ${ns_appdir}/Contents/Resources/etc for f in $(shell cd $(top_srcdir_abs)/etc; ls); do ln -s $(top_srcdir_abs)/etc/$$f ${ns_appdir}/Contents/Resources/etc; done ln -s $(abs_top_builddir)/etc/DOC ${ns_appdir}/Contents/Resources/etc diff --git a/src/Makefile.in b/src/Makefile.in index 79cddb35b5..22c7aeed5c 100644 --- a/src/Makefile.in +++ b/src/Makefile.in @@ -55,7 +55,7 @@ lwlibdir = # Configuration files for .o files to depend on. config_h = config.h $(srcdir)/conf_post.h -## ns-app if HAVE_NS, else empty. +## ns-app if NS self contained app, else empty. OTHER_FILES = @OTHER_FILES@ ## Flags to pass for profiling builds diff --git a/src/callproc.c b/src/callproc.c index e44e243680..aabc39313b 100644 --- a/src/callproc.c +++ b/src/callproc.c @@ -1661,32 +1661,15 @@ make_environment_block (Lisp_Object current_dir) void init_callproc_1 (void) { -#ifdef HAVE_NS - const char *etc_dir = ns_etc_directory (); - const char *path_exec = ns_exec_path (); -#endif - - Vdata_directory = decode_env_path ("EMACSDATA", -#ifdef HAVE_NS - etc_dir ? etc_dir : -#endif - PATH_DATA, 0); + Vdata_directory = decode_env_path ("EMACSDATA", PATH_DATA, 0); Vdata_directory = Ffile_name_as_directory (Fcar (Vdata_directory)); - Vdoc_directory = decode_env_path ("EMACSDOC", -#ifdef HAVE_NS - etc_dir ? etc_dir : -#endif - PATH_DOC, 0); + Vdoc_directory = decode_env_path ("EMACSDOC", PATH_DOC, 0); Vdoc_directory = Ffile_name_as_directory (Fcar (Vdoc_directory)); /* Check the EMACSPATH environment variable, defaulting to the PATH_EXEC path from epaths.h. */ - Vexec_path = decode_env_path ("EMACSPATH", -#ifdef HAVE_NS - path_exec ? path_exec : -#endif - PATH_EXEC, 0); + Vexec_path = decode_env_path ("EMACSPATH", PATH_EXEC, 0); Vexec_directory = Ffile_name_as_directory (Fcar (Vexec_path)); /* FIXME? For ns, path_exec should go at the front? */ Vexec_path = nconc2 (decode_env_path ("PATH", "", 0), Vexec_path); @@ -1701,10 +1684,6 @@ init_callproc (void) char *sh; Lisp_Object tempdir; -#ifdef HAVE_NS - if (data_dir == 0) - data_dir = ns_etc_directory () != 0; -#endif if (!NILP (Vinstallation_directory)) { @@ -1716,15 +1695,8 @@ init_callproc (void) /* MSDOS uses wrapped binaries, so don't do this. */ if (NILP (Fmember (tem, Vexec_path))) { -#ifdef HAVE_NS - const char *path_exec = ns_exec_path (); -#endif /* Running uninstalled, so default to tem rather than PATH_EXEC. */ - Vexec_path = decode_env_path ("EMACSPATH", -#ifdef HAVE_NS - path_exec ? path_exec : -#endif - SSDATA (tem), 0); + Vexec_path = decode_env_path ("EMACSPATH", SSDATA (tem), 0); Vexec_path = nconc2 (decode_env_path ("PATH", "", 0), Vexec_path); } diff --git a/src/emacs.c b/src/emacs.c index 60a57a693c..b7982ece64 100644 --- a/src/emacs.c +++ b/src/emacs.c @@ -835,7 +835,13 @@ load_pdump (int argc, char **argv) NULL #endif ; - const char *argv0_base = "emacs"; + const char *argv0_base = +#ifdef NS_SELF_CONTAINED + "Emacs" +#else + "emacs" +#endif + ; /* TODO: maybe more thoroughly scrub process environment in order to make this use case (loading a dump file in an unexeced emacs) @@ -912,6 +918,8 @@ load_pdump (int argc, char **argv) /* On MS-Windows, PATH_EXEC normally starts with a literal "%emacs_dir%", so it will never work without some tweaking. */ path_exec = w32_relocate (path_exec); +#elif defined (HAVE_NS) + path_exec = ns_relocate (path_exec); #endif /* Look for "emacs.pdmp" in PATH_EXEC. We hardcode "emacs" in @@ -929,6 +937,7 @@ load_pdump (int argc, char **argv) } sprintf (dump_file, "%s%c%s%s", path_exec, DIRECTORY_SEP, argv0_base, suffix); +#if !defined (NS_SELF_CONTAINED) /* Assume the Emacs binary lives in a sibling directory as set up by the default installation configuration. */ const char *go_up = "../../../../bin/"; @@ -943,6 +952,7 @@ load_pdump (int argc, char **argv) sprintf (emacs_executable, "%s%c%s%s%s", path_exec, DIRECTORY_SEP, go_up, argv0_base, strip_suffix ? strip_suffix : ""); +#endif result = pdumper_load (dump_file, emacs_executable); if (result == PDUMPER_LOAD_FILE_NOT_FOUND) @@ -2960,7 +2970,11 @@ decode_env_path (const char *evarname, const char *defalt, bool empty) path = 0; if (!path) { +#ifdef NS_SELF_CONTAINED + path = ns_relocate (defalt); +#else path = defalt; +#endif #ifdef WINDOWSNT defaulted = 1; #endif diff --git a/src/lread.c b/src/lread.c index 0b33fd0f25..4617ffd626 100644 --- a/src/lread.c +++ b/src/lread.c @@ -4769,14 +4769,9 @@ load_path_default (void) return decode_env_path (0, PATH_DUMPLOADSEARCH, 0); Lisp_Object lpath = Qnil; - const char *normal = PATH_LOADSEARCH; const char *loadpath = NULL; -#ifdef HAVE_NS - loadpath = ns_load_path (); -#endif - - lpath = decode_env_path (0, loadpath ? loadpath : normal, 0); + lpath = decode_env_path (0, PATH_LOADSEARCH, 0); if (!NILP (Vinstallation_directory)) { diff --git a/src/nsterm.h b/src/nsterm.h index f64354b8a7..b29e76cc63 100644 --- a/src/nsterm.h +++ b/src/nsterm.h @@ -1190,9 +1190,7 @@ #define NSAPP_DATA2_RUNASSCRIPT 10 #define NSAPP_DATA2_RUNFILEDIALOG 11 extern void ns_run_file_dialog (void); -extern const char *ns_etc_directory (void); -extern const char *ns_exec_path (void); -extern const char *ns_load_path (void); +extern const char *ns_relocate (const char *epath); extern void syms_of_nsterm (void); extern void syms_of_nsfns (void); extern void syms_of_nsmenu (void); diff --git a/src/nsterm.m b/src/nsterm.m index e81a4cbc0d..8497138039 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -499,118 +499,35 @@ - (NSColor *)colorUsingDefaultColorSpace const char * -ns_etc_directory (void) -/* If running as a self-contained app bundle, return as a string the - filename of the etc directory, if present; else nil. */ -{ - NSBundle *bundle = [NSBundle mainBundle]; - NSString *resourceDir = [bundle resourcePath]; - NSString *resourcePath; - NSFileManager *fileManager = [NSFileManager defaultManager]; - BOOL isDir; +ns_relocate (const char *epath) +/* If we're running in a self-contained app bundle some hard-coded + paths are relative to the root of the bundle, so work out the full + path. - resourcePath = [resourceDir stringByAppendingPathComponent: @"etc"]; - if ([fileManager fileExistsAtPath: resourcePath isDirectory: &isDir]) - { - if (isDir) return [resourcePath UTF8String]; - } - return NULL; -} - - -const char * -ns_exec_path (void) -/* If running as a self-contained app bundle, return as a path string - the filenames of the libexec and bin directories, ie libexec:bin. - Otherwise, return nil. - Normally, Emacs does not add its own bin/ directory to the PATH. - However, a self-contained NS build has a different layout, with - bin/ and libexec/ subdirectories in the directory that contains - Emacs.app itself. - We put libexec first, because init_callproc_1 uses the first - element to initialize exec-directory. An alternative would be - for init_callproc to check for invocation-directory/libexec. -*/ + FIXME: I think this should be able to handle cases where multiple + directories are separated by colons. */ { +#ifdef NS_SELF_CONTAINED NSBundle *bundle = [NSBundle mainBundle]; - NSString *resourceDir = [bundle resourcePath]; - NSString *binDir = [bundle bundlePath]; - NSString *resourcePath, *resourcePaths; - NSRange range; - NSString *pathSeparator = [NSString stringWithFormat: @"%c", SEPCHAR]; + NSString *root = [bundle bundlePath]; + NSString *original = [NSString stringWithUTF8String:epath]; + NSString *fixedPath = [NSString pathWithComponents:@[root, original]]; NSFileManager *fileManager = [NSFileManager defaultManager]; - NSArray *paths; - NSEnumerator *pathEnum; - BOOL isDir; - range = [resourceDir rangeOfString: @"Contents"]; - if (range.location != NSNotFound) - { - binDir = [binDir stringByAppendingPathComponent: @"Contents"]; -#ifdef NS_IMPL_COCOA - binDir = [binDir stringByAppendingPathComponent: @"MacOS"]; -#endif - } + if (![original isAbsolutePath] + && [fileManager fileExistsAtPath:fixedPath isDirectory:NULL]) + return [fixedPath UTF8String]; - paths = [binDir stringsByAppendingPaths: - [NSArray arrayWithObjects: @"libexec", @"bin", nil]]; - pathEnum = [paths objectEnumerator]; - resourcePaths = @""; + /* If we reach here either the path is absolute and therefore we + don't need to complete it, or we're unable to relocate the + file/directory. If it's the latter it may be because the user is + trying to use a bundled app as though it's a Unix style install + and we have no way to guess what was intended, so return the + original string unaltered. */ - while ((resourcePath = [pathEnum nextObject])) - { - if ([fileManager fileExistsAtPath: resourcePath isDirectory: &isDir]) - if (isDir) - { - if ([resourcePaths length] > 0) - resourcePaths - = [resourcePaths stringByAppendingString: pathSeparator]; - resourcePaths - = [resourcePaths stringByAppendingString: resourcePath]; - } - } - if ([resourcePaths length] > 0) return [resourcePaths UTF8String]; - - return NULL; -} - - -const char * -ns_load_path (void) -/* If running as a self-contained app bundle, return as a path string - the filenames of the site-lisp and lisp directories. - Ie, site-lisp:lisp. Otherwise, return nil. */ -{ - NSBundle *bundle = [NSBundle mainBundle]; - NSString *resourceDir = [bundle resourcePath]; - NSString *resourcePath, *resourcePaths; - NSString *pathSeparator = [NSString stringWithFormat: @"%c", SEPCHAR]; - NSFileManager *fileManager = [NSFileManager defaultManager]; - BOOL isDir; - NSArray *paths = [resourceDir stringsByAppendingPaths: - [NSArray arrayWithObjects: - @"site-lisp", @"lisp", nil]]; - NSEnumerator *pathEnum = [paths objectEnumerator]; - resourcePaths = @""; - - /* Hack to skip site-lisp. */ - if (no_site_lisp) resourcePath = [pathEnum nextObject]; - - while ((resourcePath = [pathEnum nextObject])) - { - if ([fileManager fileExistsAtPath: resourcePath isDirectory: &isDir]) - if (isDir) - { - if ([resourcePaths length] > 0) - resourcePaths - = [resourcePaths stringByAppendingString: pathSeparator]; - resourcePaths - = [resourcePaths stringByAppendingString: resourcePath]; - } - } - if ([resourcePaths length] > 0) return [resourcePaths UTF8String]; +#endif - return NULL; + return epath; } -- 2.30.2 --lW+ZmI3DrBy7gYMU-- From unknown Sun Jun 22 04:29:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS) Resent-From: Matthew Bauer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Jun 2021 20:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48994 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Alan Third , Matthew Bauer Cc: 48994@debbugs.gnu.org Received: via spool by 48994-submit@debbugs.gnu.org id=B48994.162448119119952 (code B ref 48994); Wed, 23 Jun 2021 20:47:02 +0000 Received: (at 48994) by debbugs.gnu.org; 23 Jun 2021 20:46:31 +0000 Received: from localhost ([127.0.0.1]:41912 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lw9lW-0005Bk-PJ for submit@debbugs.gnu.org; Wed, 23 Jun 2021 16:46:31 -0400 Received: from mail-ej1-f49.google.com ([209.85.218.49]:38858) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lw9lV-0005BY-Dt for 48994@debbugs.gnu.org; Wed, 23 Jun 2021 16:46:29 -0400 Received: by mail-ej1-f49.google.com with SMTP id hq39so6004723ejc.5 for <48994@debbugs.gnu.org>; Wed, 23 Jun 2021 13:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xEIi06GFzv5pBe7q23GXmy6wi7gmla0yNrNLIOl45UA=; b=rx+Cp/ZQKuM2aw29CFZBkGFj3IHVabsD6QmPzgw9XNzC3dHfuSSr7FUSIOxeAaMf7K bCo9IRaDSF8kpYIQ7K8yv4LYl1WBt+ynDfciD3KDNi/haV15LkRpyGP5jOeBdxfypmqU n9WB4d+l1eBHEnGaij3fx/3P2aKJnXQyXp8BdgHEOBs0p7bCmsP4KzDfhRHxEN3UXyCp hVzFvAKFvqt709Dnd5hyp2YzvDQtarsadwt7KrutbgMHV4+dyL24Iw8uB5/wD84hiRgZ 5dSExtot77QDY1YA+iYY6ZeQAEy5YS0kEkm0dWbHqWZJWDSohqNQtchCE45kvjVXhBpU 0pUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xEIi06GFzv5pBe7q23GXmy6wi7gmla0yNrNLIOl45UA=; b=W1Hso2ZZKIUORn69KAG4Xo5U6nH4kLzOBbnUiiy/1mFRIllnXVH4mTv5g5WYvjVFD7 7h13z6o3o/xC+7W6mLVaJmVh/nV89AlqlPfJ3ubFmMDrnht91r8KB9uDpU56Y1Al+oEJ 3vAeA95qpkktB3wqtKv59mXtC73GwePUkGOmiLHkqAXLfDgfCG9nKWrJFfA2groKfgAT so6/phffEBJBZCoJcmyMUXJdTbfD1Vu9O8zONUfT9XveUEicD17URnT7OF9t8ACzizb4 2nYbz9ENrPeCwkp+fsRfsq/fxdVab+xP7xCZT2O4UegF4YP11GX1CcwNp7hGurIRTPbJ sPhQ== X-Gm-Message-State: AOAM5323sY1M2qHlv4jWrLcpCYXzTeX0p2dePHUPvNTVG9WyF3IwVguz rEbh5imuSdqHyoVRAIQ8V64KgnsfZcXbuO0Ezk8= X-Google-Smtp-Source: ABdhPJzNDUAmz31UAfMLSp/AQBgEnWrvb90LIV4eExkhUXQ3c8hf7QC8XUqxMYixClV8/jIv884eAr+QcHGb+dTjXmA= X-Received: by 2002:a17:907:20da:: with SMTP id qq26mr1874696ejb.42.1624481183420; Wed, 23 Jun 2021 13:46:23 -0700 (PDT) MIME-Version: 1.0 References: <835yyg5k4p.fsf@gnu.org> <83fsxh1wdd.fsf@gnu.org> In-Reply-To: From: Matthew Bauer Date: Wed, 23 Jun 2021 15:46:12 -0500 Message-ID: Content-Type: multipart/alternative; boundary="000000000000e1d3e205c574ffed" X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --000000000000e1d3e205c574ffed Content-Type: text/plain; charset="UTF-8" That works for me! No apparent issues. On Wed, Jun 23, 2021 at 10:59 AM Alan Third wrote: > On Tue, Jun 22, 2021 at 06:01:25PM -0500, Matthew Bauer wrote: > > > Turns out there's another variable that should only be set when > > > building the app. > > > > > Please try the attached patch. > > > > That works for me ! > > > > So previously the nextstep/Emacs.app was getting generated even > > with --disable-ns-self-contained. I think that's fine to not build in > > this case - in fact it duplicates the Emacs executable - but just a note > > that it kind of changes things for packages. I have a fix for Nixpkgs > > (which previously installed nexstep/Emacs.app), but I think > > homebrew-emacs-plus would also be effected: > > > > https://github.com/d12frosted/homebrew-emacs-plus > > This sounds like madness to me, but I see it's a supported > configuration mentioned in our install files. > > So, attempt three attached! > -- > Alan Third > --000000000000e1d3e205c574ffed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That works for me! No apparent issues.

On Wed, Jun 23, 2021= at 10:59 AM Alan Third <alan@idiocy.= org> wrote:
On Tue, Jun 22, 2021 at 06:01:= 25PM -0500, Matthew Bauer wrote:
> > Turns out there's another variable that should only be set wh= en
> > building the app.
>
> > Please try the attached patch.
>
> That works for me !
>
> So previously the nextstep/Emacs.app was getting generated even
> with --disable-ns-self-contained. I think that's fine to not build= in
> this case - in fact it duplicates the Emacs executable - but just a no= te
> that it kind of changes things for packages. I have a fix for Nixpkgs<= br> > (which previously installed nexstep/Emacs.app), but I think
> homebrew-emacs-plus would also be effected:
>
> https://github.com/d12frosted/homebrew-emacs-p= lus

This sounds like madness to me, but I see it's a supported
configuration mentioned in our install files.

So, attempt three attached!
--
Alan Third
--000000000000e1d3e205c574ffed-- From unknown Sun Jun 22 04:29:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS) Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Jun 2021 20:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48994 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Matthew Bauer Cc: 48994@debbugs.gnu.org Received: via spool by 48994-submit@debbugs.gnu.org id=B48994.162448130220142 (code B ref 48994); Wed, 23 Jun 2021 20:49:01 +0000 Received: (at 48994) by debbugs.gnu.org; 23 Jun 2021 20:48:22 +0000 Received: from localhost ([127.0.0.1]:41916 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lw9nK-0005En-7f for submit@debbugs.gnu.org; Wed, 23 Jun 2021 16:48:22 -0400 Received: from outbound.soverin.net ([116.202.126.228]:48809) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lw9nI-0005EY-H9 for 48994@debbugs.gnu.org; Wed, 23 Jun 2021 16:48:21 -0400 Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 42E9E955; Wed, 23 Jun 2021 20:48:14 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1624481293; bh=1eLu+x0oTEDuovrSO+my7OAe3eINpMfMelpPEu2Eisg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LxTSz1BhYCIqsFzjUSoM4K07N4SoQvhnftTrOFt4imYaxObQTk/MkW+fSAQGuk526 XXDiF5idIxz4VOKLKYe7ZC/zD698mzD/bOatfp9jXAAt/CTFpmHrir9yZoj2OCgy/K hK0WMol8AN97PPGiX6JB/G06dqzuU8AAGrotPmEcWuHbKz3rO1P5gAhVY5aP21MwSE byoFK2X4uTUPLzrKE0d2SA6J090h4E3wrGzBAWlRIsyO5I/uR+utHs90L5/xMnIDqM XU8nKx3tVoCSOW2MgdQE80+G75m+ZCXirR/TPNXQZTdI9/LC2uRwAyC2DXHt3DfIlv J6AoHExhHOqfA== Received: from alan by faroe.holly.idiocy.org with local (Exim 4.94.2) (envelope-from ) id 1lw9n9-001FsW-92; Wed, 23 Jun 2021 21:48:11 +0100 Date: Wed, 23 Jun 2021 21:48:11 +0100 From: Alan Third Message-ID: Mail-Followup-To: Alan Third , Matthew Bauer , 48994@debbugs.gnu.org References: <83fsxh1wdd.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Thanks! I'll leave it a few days before pushing it just in case anyone else spots anything wrong with it. On Wed, Jun 23, 2021 at 03:46:12PM -0500, Matthew Bauer wrote: > That works for me! No apparent issues. > > On Wed, Jun 23, 2021 at 10:59 AM Alan Third wrote: > > > On Tue, Jun 22, 2021 at 06:01:25PM -0500, Matthew Bauer wrote: > > > > Turns out there's another variable that should only be set when > > > > building the app. > > > > > > > Please try the attached patch. > > > > > > That works for me ! > > > > > > So previously the nextstep/Emacs.app was getting generated even > > > with --disable-ns-self-contained. I think that's fine to not build in > > > this case - in fact it duplicates the Emacs executable - but just a note > > > that it kind of changes things for packages. I have a fix for Nixpkgs > > > (which previously installed nexstep/Emacs.app), but I think > > > homebrew-emacs-plus would also be effected: > > > > > > https://github.com/d12frosted/homebrew-emacs-plus > > > > This sounds like madness to me, but I see it's a supported > > configuration mentioned in our install files. > > > > So, attempt three attached! > > -- Alan Third From unknown Sun Jun 22 04:29:51 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Matthew Bauer Subject: bug#48994: closed (Re: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS)) Message-ID: References: X-Gnu-PR-Message: they-closed 48994 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: patch Reply-To: 48994@debbugs.gnu.org Date: Sat, 26 Jun 2021 09:39:01 +0000 Content-Type: multipart/mixed; boundary="----------=_1624700341-9678-1" This is a multi-part message in MIME format... ------------=_1624700341-9678-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompil= es .eln (macOS) which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 48994@debbugs.gnu.org. --=20 48994: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D48994 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1624700341-9678-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 48994-done) by debbugs.gnu.org; 26 Jun 2021 09:38:35 +0000 Received: from localhost ([127.0.0.1]:47135 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lx4lm-0002VM-PO for submit@debbugs.gnu.org; Sat, 26 Jun 2021 05:38:35 -0400 Received: from outbound.soverin.net ([116.202.126.228]:48133) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lx4li-0002V2-Ak for 48994-done@debbugs.gnu.org; Sat, 26 Jun 2021 05:38:33 -0400 Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 06412937; Sat, 26 Jun 2021 09:38:23 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1624700302; bh=wfubJcBWJYOygLkwivsaBb3lE7K2lrpnOV916+w/h5g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=aT348SQH652wi69bHb+9eFucIBRBogRT6Hz7NwsCGai5GEsAqy7rTwtju9uUAHNUG FWRqzZiVqPrOGKWr/L6FqANEBfx/joAml/Jtfq2a1lE5qR7j5wpRHB3rfStKsnphlo SCP9yCiJFLHob4NCfyJHmrhBTZCxMXvusyT2o76WBE33xY5buzq90OdAaR1vLOXcrn yBA4mCcdrXfs/hBwRZdvbNgdMJuc0BOnnRuNITnZavLkZn06wP/01qYxEvni45/Gaz TuRoq2vsSJISTB7XGWod4ygJcJnmxCVQfbZcqU2AKSy7BPvoX5rRu+4LuK1PqlrCqI xf+jXrmS917/A== Received: from alan by faroe.holly.idiocy.org with local (Exim 4.94.2) (envelope-from ) id 1lx4lX-001Nd2-Sk; Sat, 26 Jun 2021 10:38:19 +0100 Date: Sat, 26 Jun 2021 10:38:19 +0100 From: Alan Third To: Matthew Bauer Subject: Re: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS) Message-ID: Mail-Followup-To: Alan Third , Matthew Bauer , 48994-done@debbugs.gnu.org References: <83fsxh1wdd.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 48994-done Cc: 48994-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) I've pushed it to master. Thanks! On Wed, Jun 23, 2021 at 03:46:12PM -0500, Matthew Bauer wrote: > That works for me! No apparent issues. > > On Wed, Jun 23, 2021 at 10:59 AM Alan Third wrote: > > > On Tue, Jun 22, 2021 at 06:01:25PM -0500, Matthew Bauer wrote: > > > > Turns out there's another variable that should only be set when > > > > building the app. > > > > > > > Please try the attached patch. > > > > > > That works for me ! > > > > > > So previously the nextstep/Emacs.app was getting generated even > > > with --disable-ns-self-contained. I think that's fine to not build in > > > this case - in fact it duplicates the Emacs executable - but just a note > > > that it kind of changes things for packages. I have a fix for Nixpkgs > > > (which previously installed nexstep/Emacs.app), but I think > > > homebrew-emacs-plus would also be effected: > > > > > > https://github.com/d12frosted/homebrew-emacs-plus > > > > This sounds like madness to me, but I see it's a supported > > configuration mentioned in our install files. > > > > So, attempt three attached! > > -- Alan Third ------------=_1624700341-9678-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 13 Jun 2021 03:13:20 +0000 Received: from localhost ([127.0.0.1]:42415 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lsGYq-0008Gx-6X for submit@debbugs.gnu.org; Sat, 12 Jun 2021 23:13:20 -0400 Received: from lists.gnu.org ([209.51.188.17]:52972) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lsGYo-0008Gq-Sm for submit@debbugs.gnu.org; Sat, 12 Jun 2021 23:13:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60452) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lsGYo-00081V-N2 for bug-gnu-emacs@gnu.org; Sat, 12 Jun 2021 23:13:18 -0400 Received: from mail-ot1-x32a.google.com ([2607:f8b0:4864:20::32a]:34484) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lsGYm-0008Mu-Sb for bug-gnu-emacs@gnu.org; Sat, 12 Jun 2021 23:13:18 -0400 Received: by mail-ot1-x32a.google.com with SMTP id w22-20020a0568304116b02904060c6415c7so5002602ott.1 for ; Sat, 12 Jun 2021 20:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version; bh=+6dcHQuS18Mh3ncvCFU+2MoyZ+/txQfEO3/sqpovXts=; b=t8rBJdqh4H2f4Iev7ZiFbYqZX96yRlJnXXAg1vPZYwoQgLSoT1pn5yeYlbp8k+AVJk 4FjxQlS2iiz7AyZcJnfA3GP3vjxKrOyouo4zEKWaNPmIWIERBznXkURQFEtWhtfBY/2Q 7AIjNC3+Z52oFihjyANDijIzMOoOZljz9LB2SdfWk4tYV4loOKRLEwY71Equ5DlyFqBT pKo7FiOhDXw521mOc8/h4/NSvJ4ww55jMmu7tAxKIDSRxVYcxHUkrnQ2yaGtC1GCUJd9 mCP64eQD7Q5ui+DrAJbRVrBiztS7xvx5EN6nknZxrjIxQ/VNKgHHaYJ1rsm5A6SkjD8e /VUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version; bh=+6dcHQuS18Mh3ncvCFU+2MoyZ+/txQfEO3/sqpovXts=; b=cJgA9DVSV3Av13mwzD1SpW+lVrkkpa7sXYU3BbmblTBn/HYey3NisTcmA2m3hCHDHD kamOpL8aeqAzTqNTIbMb/GfzfmDKsbaFrTyJBOOJZP7wXIGFAuXilNwBEoVJvIMhmzUf U4VmyCQBxPE6HxnBcN7wYGWcFcuOByWzGC36grfuQMo9YifuKdZs5nSlby0oYR/8UrB3 M9rwdo/hbqnBJXtFI3YUwxusmyWrP+OchpOoU9vAXAxBwPWbmp2M/X0Tc/CvZt/07RkA bLgdFWGci5EmsxkQSaTee2s8ZvV9/ueqCxZA1hcduXlVOLT8CiIqH0Mzdh5E7kq3Qkja kzUw== X-Gm-Message-State: AOAM532kyNgXwS+LWvTRF4vEu8Gj/B2qDsGsu5gSfJSn9mCmCq84eoCC 9tK1+kUxm9OMwIhnE7Nai9U= X-Google-Smtp-Source: ABdhPJzwn598XAFUdKeOYiwuIo39d9dgJv3zn33P5BUvfz5MoOJh3ZuPAej2fBCYO1Ga9S8Hlcr6Eg== X-Received: by 2002:a9d:6f0d:: with SMTP id n13mr8858393otq.168.1623553994849; Sat, 12 Jun 2021 20:13:14 -0700 (PDT) Received: from mac-mini.lan ([2605:a601:ac7b:7f00:2d69:8908:249:46b8]) by smtp.gmail.com with ESMTPSA id w8sm2324729otk.16.2021.06.12.20.13.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 12 Jun 2021 20:13:14 -0700 (PDT) From: Matthew Bauer To: bug-gnu-emacs@gnu.org Subject: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS) Date: Sat, 12 Jun 2021 22:13:13 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=2607:f8b0:4864:20::32a; envelope-from=mjbauer95@gmail.com; helo=mail-ot1-x32a.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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_ENVFROM_END_DIGIT=0.25, 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.1 (-) X-Debbugs-Envelope-To: submit Cc: Andrea Corallo X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is similar to bug#48497, but appears to still happen even after commit 3f207753a0. The basic problem is that the installed lisp path does not match either of the search expressions in comp-el-to-eln-rel-filename, meaning that native lisp needs to be recompiled needlessly. The problem seems to come from PATH_REL_LOADSEARCH being set for me (on macOS) to Contents/Resources/lisp, but the lisp files actually being installed to /nix/store/...-emacs-gcc-20210612.0/share/emacs/28.0.50/lisp (path generated by Nix). As a result, comp-el-to-eln-rel-filename used the filename comp-034d3699-516ce4bf.eln for comp.el.gz where 516ce4bf is the md5sum of the contents of comp.el and 034d3699 is the md5sum of the full path of comp.el, not of //emacs-lisp/comp.el (7672a6ed), which is what Emacs installs. To fix this, I propose using PATH_LOADSEARCH in addition to PATH_REL_LOADSEARCH so that we can catch both types of macOS installs (.app and unix). I=E2=80=99ve attached a patch which implements this, adding relative and absolute loadsearch resolution. - Matthew --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Use-PATH_LOADSEARCH-to-get-absolute-path-of-native-c.patch >From 32022ee8d977196c72ad42d89d23142a6e59ff8e Mon Sep 17 00:00:00 2001 From: Matthew Bauer Date: Sat, 12 Jun 2021 00:37:28 -0500 Subject: [PATCH] Use PATH_LOADSEARCH to get absolute path of native comp We need to so that /usr/local/share/emacs/28.0.50/lisp/emacs-lisp/comp.el becomes: //emacs-lisp/comp.el which is what we install eln files as. --- src/comp.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/src/comp.c b/src/comp.c index 056d0860d8..8ccd99d583 100644 --- a/src/comp.c +++ b/src/comp.c @@ -4049,12 +4049,14 @@ DEFUN ("comp-el-to-eln-rel-filename", Fcomp_el_to_eln_rel_filename, As installing .eln files compiled during the build changes their absolute path we need an hashing mechanism that is not sensitive - to that. For this we replace if match PATH_DUMPLOADSEARCH or - *PATH_REL_LOADSEARCH with '//' before computing the hash. */ + to that. For this we replace if match PATH_DUMPLOADSEARCH, + PATH_REL_LOADSEARCH, or PATH_LOADSEARCH with '//' before + computing the hash. */ if (NILP (loadsearch_re_list)) { - Lisp_Object sys_re = + Lisp_Object sys_abs_re = Fregexp_quote (build_string (PATH_LOADSEARCH "/")); + Lisp_Object sys_rel_re = concat2 (build_string ("\\`[[:ascii:]]+"), Fregexp_quote (build_string ("/" PATH_REL_LOADSEARCH "/"))); Lisp_Object dump_load_search = @@ -4062,7 +4064,7 @@ DEFUN ("comp-el-to-eln-rel-filename", Fcomp_el_to_eln_rel_filename, #ifdef WINDOWSNT dump_load_search = Fw32_long_file_name (dump_load_search); #endif - loadsearch_re_list = list2 (sys_re, Fregexp_quote (dump_load_search)); + loadsearch_re_list = list3 (sys_abs_re, sys_rel_re, Fregexp_quote (dump_load_search)); } Lisp_Object lds_re_tail = loadsearch_re_list; -- 2.29.2 --=-=-=-- ------------=_1624700341-9678-1--