GNU bug report logs - #16429
EMACSDATA in the MS Windows registry can interfere with building

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16429 in the body.
You can then email your comments to 16429 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: zijianyue <zijianyue <at> 163.com>
To: bug-gnu-emacs <bug-gnu-emacs <at> gnu.org>
Subject: 24.3.50; an issue in mingw making
Date: Mon, 13 Jan 2014 15:11:33 +0800

[Message part 1 (text/plain, inline)]

*** E-Mail body has been placed on clipboard, please paste it here! ***

when making emacs from bzr sourcecode the first time on win32 ,the dir
share\emacs\24.3.50\etc\charsets is not exist ,but the making process
require it,i have to copy that dir manually.



In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
of 2014-01-13 on XP-201104270939
Repository revision: dancol <at> dancol.org-20140113015046-zvywal17fjhhwx25
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
`configure --prefix=/e/emacs --enable-checking 'CFLAGS=-O0 -g3'
CPPFLAGS=-DGLYPH_DEBUG=1'

Important settings:
  value of $EMACSDATA: E:/emacs/share/emacs/24.3.50/etc
  value of $EMACSDOC: E:/emacs/share/emacs/24.3.50/etc
  value of $EMACSLOADPATH: E:/emacs/share/emacs/24.3.50/site-lisp;E:/emacs/share/emacs/site-lisp;E:/emacs/share/emacs/24.3.50/lisp
  value of $EMACSPATH: E:/emacs/libexec/emacs/24.3.50/i686-pc-mingw32
  value of $LANG: CHS
  locale-coding-system: cp936

Major mode: Fundamental

Minor modes in effect:
  recent-jump-small-mode: t
  diff-auto-refine-mode: t
  global-auto-complete-mode: t
  delete-selection-mode: t
  which-function-mode: t
  show-paren-mode: t
  global-auto-revert-mode: t
  electric-pair-mode: t
  cua-mode: t
  global-ede-mode: t
  global-semanticdb-minor-mode: t
  global-semantic-idle-scheduler-mode: t
  global-semantic-idle-summary-mode: t
  semantic-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<down-mouse-1> <mouse-1> <down-mouse-1> <help-echo> 
<mouse-movement> <mouse-movement> <help-echo> <mouse-movement> 
<help-echo> <mouse-movement> <help-echo> <mouse-movement> 
<help-echo> <mouse-movement> <help-echo> <mouse-movement> 
<mouse-movement> <help-echo> <mouse-movement> <help-echo> 
<mouse-movement> <mouse-movement> <help-echo> <mouse-movement> 
<mouse-movement> <drag-mouse-1> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <down-mouse-1> 
<mouse-1> <help-echo> <down-mouse-1> <mouse-movement> 
<mouse-movement> <help-echo> <mouse-movement> <help-echo> 
<mouse-movement> <help-echo> <mouse-movement> <mouse-movement> 
<help-echo> <mouse-movement> <help-echo> <mouse-movement> 
<help-echo> <mouse-movement> <help-echo> <mouse-movement> 
<help-echo> <mouse-movement> <mouse-movement> <help-echo> 
<help-echo> <mouse-movement> <mouse-movement> <help-echo> 
<mouse-movement> <help-echo> <mouse-movement> <mouse-movement> 
<drag-mouse-1> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <down-mouse-1> 
<mouse-1> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <down-mouse-1> 
<help-echo> <mouse-movement> <help-echo> <mouse-movement> 
<mouse-movement> <help-echo> <mouse-movement> <help-echo> 
<mouse-movement> <help-echo> <mouse-movement> <help-echo> 
<mouse-movement> <help-echo> <mouse-movement> <help-echo> 
<mouse-movement> <help-echo> <mouse-movement> <help-echo> 
<mouse-movement> <help-echo> <mouse-movement> <mouse-movement> 
<help-echo> <drag-mouse-1> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <down-mouse-1> <mouse-movement> <drag-mouse-1> 
<help-echo> <down-mouse-1> <mouse-movement> <mouse-movement> 
<help-echo> <mouse-movement> <help-echo> <mouse-movement> 
<mouse-movement> <help-echo> <mouse-movement> <help-echo> 
<mouse-movement> <help-echo> <mouse-movement> <help-echo> 
<mouse-movement> <help-echo> <mouse-movement> <mouse-movement> 
<help-echo> <help-echo> <mouse-movement> <mouse-movement> 
<help-echo> <mouse-movement> <help-echo> <mouse-movement> 
<mouse-movement> <help-echo> <drag-mouse-1> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <down-mouse-1> 
<mouse-1> <help-echo> <down-mouse-1> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <mouse-movement> 
<mouse-movement> <drag-mouse-1> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <down-mouse-1> 
<mouse-1> <help-echo> <help-echo> <down-mouse-1> <mouse-movement> 
<mouse-movement> <help-echo> <mouse-movement> <help-echo> 
<mouse-movement> <mouse-movement> <help-echo> <mouse-movement> 
<help-echo> <mouse-movement> <help-echo> <mouse-movement> 
<help-echo> <mouse-movement> <help-echo> <mouse-movement> 
<help-echo> <mouse-movement> <mouse-movement> <help-echo> 
<mouse-movement> <help-echo> <mouse-movement> <mouse-movement> 
<drag-mouse-1> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <down-mouse-1> <mouse-1> <help-echo> <help-echo> 
<help-echo> <down-mouse-1> <mouse-movement> <mouse-movement> 
<help-echo> <mouse-movement> <help-echo> <mouse-movement> 
<help-echo> <mouse-movement> <mouse-movement> <help-echo> 
<mouse-movement> <help-echo> <mouse-movement> <help-echo> 
<mouse-movement> <help-echo> <mouse-movement> <help-echo> 
<mouse-movement> <mouse-movement> <help-echo> <help-echo> 
<mouse-movement> <mouse-movement> <help-echo> <mouse-movement> 
<help-echo> <mouse-movement> <mouse-movement> <help-echo> 
<drag-mouse-1> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <down-mouse-1> <mouse-1> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar> 
<help-menu> <send-emacs-bug-report>

Recent messages:
Mark saved where search started
The ECB is now deactivated.
Mark set [4 times]
(New file)
Mark set [2 times]
byte-code: Beginning of buffer [4 times]
Buffer adf modified; kill anyway?  y
(New file)
Buffer adfads modified; kill anyway?  y
q is undefined

Load-path shadows:
e:/emacs/share/emacs/site-lisp/expand-region-master/features/support/env hides e:/emacs/share/emacs/24.3.50/lisp/env

Features:
(shadow sort mail-extr emacsbug message format-spec rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mail-utils url-util
url-parse auth-source gnus-util mm-util mail-prsvr password-cache
url-vars eldoc semantic/symref/global cedet-global semantic/symref/list
semantic/complete eieio-opt find-func semantic/symref hl-line hi-lock
misearch multi-isearch semantic/tag-write semantic/analyze/complete
ede/locate semantic/db-typecache semantic/ia semantic/senator
ecb-layout-defs cus-edit warnings ecb ecb-symboldef ecb-analyse
ecb-compatibility ecb-winman-support ecb-autogen autoload lisp-mnt
ecb-tod ecb-cycle ecb-eshell ecb-help ecb-jde ecb-method-browser
hideshow ecb-semantic-wrapper ecb-semantic ecb-file-browser ecb-speedbar
ecb-layout compile comint ansi-color ecb-create-layout ecb-compilation
ecb-common-browser ecb-navigate ecb-mode-line ecb-face tree-buffer
ecb-upgrade ecb-cedet-wrapper ecb-util info semantic/imenu semantic/sb
vc-dispatcher vc-svn semantic/tag-file semantic/db-file data-debug
cedet-files semantic/bovine/c semantic/decorate/include
semantic/decorate/mode semantic/decorate pulse hideif
semantic/bovine/c-by semantic/lex-spp semantic/bovine/gcc semantic/dep
semantic/bovine semantic/analyze/refs semantic/db-find semantic/db-ref
semantic/analyze semantic/sort semantic/scope semantic/analyze/fcn
cc-langs cc-mode-expansions cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs gtags sln-mode
project-buffer-occur project-buffer-mode+ project-buffer-mode ewoc
ede/cpp-root help-mode recent-jump-small recent-jump ring desktop
frameset fsvn fsvn-win mw32cmp mw32script fsvn-admin fsvn-blame
fsvn-tortoise fsvn-proclist fsvn-dired dired-aux fsvn-pub fsvn-magic
fsvn-browse fsvn-parasite fsvn-msgedit fsvn-select fsvn-propview
fsvn-logview fsvn-diff diff-mode easy-mmode diff fsvn-minibuf fsvn-popup
fsvn-mode fsvn-ui fsvn-cmd fsvn-config fsvn-fs fsvn-url fsvn-debug
fsvn-data fsvn-xml xml fsvn-proc fsvn-deps fsvn-env dired
auto-complete-config auto-complete cl-macs popup cl redo+ edmacro kmacro
expand-region text-mode-expansions er-basic-expansions thingatpt
expand-region-custom expand-region-core advice help-fns saveplace
dichromacy-theme delsel which-func imenu paren autorevert filenotify
elec-pair cua-base cus-start cus-load ede/speedbar ede/files ede
ede/base ede/auto ede/source eieio-speedbar speedbar sb-image dframe
eieio-custom wid-edit cl-loaddefs cl-lib semantic/db-mode semantic/db gv
eieio-base semantic/idle semantic/format ezimage semantic/tag-ls
semantic/find semantic/ctxt semantic/util-modes easymenu semantic/util
semantic semantic/tag semantic/lex semantic/fw eieio byte-opt bytecomp
byte-compile cconv eieio-core mode-local cedet server time-date
china-util tooltip electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel dos-w32 ls-lisp w32-common-fns disp-table w32-win w32-vars
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
w32notify w32 multi-tty emacs)




zijianyue

[Message part 2 (text/html, inline)]

Message #8 received at 16429 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: zijianyue <zijianyue <at> 163.com>
Cc: 16429 <at> debbugs.gnu.org
Subject: Re: bug#16429: 24.3.50; an issue in mingw making
Date: Mon, 13 Jan 2014 18:53:32 +0200

> Date: Mon, 13 Jan 2014 15:11:33 +0800
> From: zijianyue <zijianyue <at> 163.com>
> 
> when making emacs from bzr sourcecode the first time on win32 ,the dir
> share\emacs\24.3.50\etc\charsets is not exist ,but the making process
> require it,i have to copy that dir manually.

I cannot reproduce this: when I make a fresh bzr branch, that
directory with all its files is already created for me.

How did you perform the initial bzr branch command?

Message #11 received at 16429 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: zijianyue <zijianyue <at> 163.com>
Cc: 16429 <at> debbugs.gnu.org
Subject: Re: bug#16429: 24.3.50; an issue in mingw making
Date: Mon, 13 Jan 2014 12:01:39 -0500

zijianyue wrote:

> when making emacs from bzr sourcecode the first time on win32 ,the dir
> share\emacs\24.3.50\etc\charsets is not exist ,but the making process
> require it,i have to copy that dir manually.

It should work without it, and apparently does for most people.

Note that you have the following environment variables set.
There's no need to have these set (unless you want to do something
unusual), and setting them is a great way to break Emacs in exactly the
way you seem to describe above.

So try unsetting them before you build.

The build process should probably unset EMACSDATA (and DOC?), like it
does with EMACSLOADPATH. I guess EMACSPATH doesn't matter?

>   value of $EMACSDATA: E:/emacs/share/emacs/24.3.50/etc
>   value of $EMACSDOC: E:/emacs/share/emacs/24.3.50/etc
>   value of $EMACSLOADPATH: E:/emacs/share/emacs/24.3.50/site-lisp;E:/emacs/share/emacs/site-lisp;E:/emacs/share/emacs/24.3.50/lisp
>   value of $EMACSPATH: E:/emacs/libexec/emacs/24.3.50/i686-pc-mingw32

Message #14 received at 16429 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: zijianyue <at> 163.com, 16429 <at> debbugs.gnu.org
Subject: Re: bug#16429: 24.3.50; an issue in mingw making
Date: Mon, 13 Jan 2014 19:44:35 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Date: Mon, 13 Jan 2014 12:01:39 -0500
> Cc: 16429 <at> debbugs.gnu.org
> 
> Note that you have the following environment variables set.

They could be either in the environment or in the Registry.  If
neither of these is set, we will not see these variables in the bug
report.

> There's no need to have these set (unless you want to do something
> unusual), and setting them is a great way to break Emacs in exactly the
> way you seem to describe above.

Right.

> So try unsetting them before you build.

If they are in the Registry, they should be deleted with regedit.

> The build process should probably unset EMACSDATA (and DOC?), like it
> does with EMACSLOADPATH.

Not sure whether we care about EMACSDOC during the build.

> I guess EMACSPATH doesn't matter?

I don't think it does.

Message #17 received at 16429 <at> debbugs.gnu.org (full text, mbox):

From: zijianyue <zijianyue <at> 163.com>
To: "Eli Zaretskii" <eliz <at> gnu.org>
Cc: 16429 <16429 <at> debbugs.gnu.org>
Subject: Re: Re: bug#16429: 24.3.50; an issue in mingw making
Date: Tue, 14 Jan 2014 09:12:39 +0800

[Message part 1 (text/plain, inline)]

thanks! I use Tortoise Bazaar ,checkout from bzr://bzr.sv.gnu.org/emacs/trunk .
my environment was create by clicking the program addpm.exe .





zijianyue

From: Eli Zaretskii
Date: 2014-01-14 00:53
To: zijianyue
CC: 16429
Subject: Re: bug#16429: 24.3.50; an issue in mingw making
> Date: Mon, 13 Jan 2014 15:11:33 +0800
> From: zijianyue <zijianyue <at> 163.com>
> 
> when making emacs from bzr sourcecode the first time on win32 ,the dir
> share\emacs\24.3.50\etc\charsets is not exist ,but the making process
> require it,i have to copy that dir manually.

I cannot reproduce this: when I make a fresh bzr branch, that
directory with all its files is already created for me.

How did you perform the initial bzr branch command?

[Message part 2 (text/html, inline)]

Message #20 received at 16429 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: zijianyue <zijianyue <at> 163.com>
Cc: 16429 <at> debbugs.gnu.org
Subject: Re: bug#16429: 24.3.50; an issue in mingw making
Date: Tue, 14 Jan 2014 07:01:34 +0200

> Date: Tue, 14 Jan 2014 09:12:39 +0800
> From: zijianyue <zijianyue <at> 163.com>
> Cc: 16429 <16429 <at> debbugs.gnu.org>
> 
> thanks! I use Tortoise Bazaar ,checkout from bzr://bzr.sv.gnu.org/emacs/trunk .
> my environment was create by clicking the program addpm.exe .

Do you really have no directory etc/charsets when you checkout from
bzr?  Or did Emacs complain about that, and you therefore thought the
directory didn't exist?

As for addpm.exe, I advise you not to use it anymore.  It is not
needed, and just pollutes the Registry with settings that are
redundant, and could harm you, as Glenn points out.  We still provide
that program only for back-compatibility and for non-standard setups.

Message #23 received at 16429 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: zijianyue <zijianyue <at> 163.com>, 16429 <at> debbugs.gnu.org
Subject: Re: bug#16429: 24.3.50; an issue in mingw making
Date: Tue, 18 Mar 2014 22:32:00 +0100

Is anything else to be done in this report, or can we close it?

Message #26 received at 16429 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: zijianyue <at> 163.com, 16429 <at> debbugs.gnu.org
Subject: Re: bug#16429: 24.3.50; an issue in mingw making
Date: Wed, 19 Mar 2014 05:49:23 +0200

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Tue, 18 Mar 2014 22:32:00 +0100
> Cc: zijianyue <zijianyue <at> 163.com>, 16429 <at> debbugs.gnu.org
> 
> Is anything else to be done in this report, or can we close it?

I think we can close it.

Message #31 received at 16429-done <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: zijianyue <at> 163.com, 16429-done <at> debbugs.gnu.org
Subject: Re: bug#16429: 24.3.50; an issue in mingw making
Date: Wed, 19 Mar 2014 05:00:00 +0100

OK, done.

Message #34 received at 16429 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: zijianyue <zijianyue <at> 163.com>, Eli Zaretskii <eliz <at> gnu.org>,
 16429 <at> debbugs.gnu.org
Subject: Re: bug#16429: 24.3.50; an issue in mingw making
Date: Wed, 19 Mar 2014 02:26:47 -0400

Juanma Barranquero wrote:

> Is anything else to be done in this report, or can we close it?

It still needs fixing.

The build process should be robust against EMACSDATA (and DOC, PATH, if
they matter) being previously set in the user's environment (and
registry on MS Windows, if possible).

In other words, something like:

export EMACSDATA=/path/to/emacs/21/etc

should not break a subsequent build of Emacs 24.4 in that environment.


The fix is to use EMACSDATA= where appropriate in the Makefiles,
and to change emacs to ignore an empty value. Or to unset EMACSDATA in
the Makefiles.

Message #43 received at 16429 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 16429 <at> debbugs.gnu.org
Subject: Re: bug#16429: 24.3.50; an issue in mingw making
Date: Fri, 11 Apr 2014 02:55:47 -0400

Fixed for POSIX platforms.
Leaving open with downgraded severity since the MS Windows registry
could presumably still be a problem.

Message #50 received at 16429 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 18765 <at> debbugs.gnu.org, 16429 <at> debbugs.gnu.org
Subject: Re: bug#18765: Re: Re: Re: bug#18765: Emacs 24.4 release candidate
 1:	"term/w32-win.el"	is	missing on Windows
Date: Tue, 21 Oct 2014 17:15:47 -0400

Eli Zaretskii wrote:

> If you know how, please suggest a method.

Either a command-line option meaning "ignore the registry", which gets
added to the Makefile Emacs flags; or, if environment variables trump
the registry, change it so that empty environment variables mean "use
the defaults" (right now they just break things), and change the
Makefiles to set empty environment variables rather than unsetting them
like they do now (seemed not straightforward last time I looked).

Message #53 received at 16429 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 18765 <at> debbugs.gnu.org, 16429 <at> debbugs.gnu.org
Subject: Re: bug#18765: Re: Re: Re: bug#18765: Emacs 24.4 release candidate
 1:	"term/w32-win.el"	is	missing on Windows
Date: Wed, 22 Oct 2014 05:49:16 +0300

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: 18765 <at> debbugs.gnu.org, 16429 <at> debbugs.gnu.org
> Date: Tue, 21 Oct 2014 17:15:47 -0400
> 
> Eli Zaretskii wrote:
> 
> > If you know how, please suggest a method.
> 
> Either a command-line option meaning "ignore the registry", which gets
> added to the Makefile Emacs flags

How does this help when the user just invokes "emacs" with no options,
as in this case?

> or, if environment variables trump the registry, change it so that
> empty environment variables mean "use the defaults" (right now they
> just break things), and change the Makefiles to set empty
> environment variables rather than unsetting them like they do now
> (seemed not straightforward last time I looked).

Why are you talking about the Makefile?  The problem ws not in
invoking Emacs from the Makefile, it was in interactive usage after
the build is done (in bug #18765).

Message #56 received at 16429 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 18765 <at> debbugs.gnu.org, 16429 <at> debbugs.gnu.org
Subject: Re: bug#18765: Re: Re: Re: bug#18765: Emacs 24.4 release candidate
 1:	"term/w32-win.el"	is	missing on Windows
Date: Wed, 22 Oct 2014 00:43:06 -0400

Eli Zaretskii wrote:

> Why are you talking about the Makefile?  The problem ws not in
> invoking Emacs from the Makefile, it was in interactive usage after
> the build is done (in bug #18765).

Oh, durr, I wasn't paying attention, sorry.

Message #59 received at 16429 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: zijianyue <zijianyue <at> 163.com>, Juanma Barranquero <lekktu <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, 16429 <at> debbugs.gnu.org
Subject: Re: bug#16429: EMACSDATA in the MS Windows registry can interfere
 with building
Date: Thu, 21 Apr 2022 15:37:19 +0200

Glenn Morris <rgm <at> gnu.org> writes:

> In other words, something like:
>
> export EMACSDATA=/path/to/emacs/21/etc
>
> should not break a subsequent build of Emacs 24.4 in that environment.
>
> The fix is to use EMACSDATA= where appropriate in the Makefiles,
> and to change emacs to ignore an empty value. Or to unset EMACSDATA in
> the Makefiles.

I see that this was added recently:

745580a36dc (Glenn Morris      2022-01-12  322) # Prevent any settings in the user environment causing problems.
745580a36dc (Glenn Morris      2022-01-12  323) unexport EMACSDATA EMACSDOC EMACSLOADPATH EMACSPATH

Does this mean that the problem reported here is now also fixed?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #64 received at 16429 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 16429 <at> debbugs.gnu.org
Subject: Re: bug#16429: EMACSDATA in the MS Windows registry can interfere
 with building
Date: Thu, 21 Apr 2022 11:26:07 -0400

0cbc41322e clearly adds nothing relevant over e088b01d29.
so the comments from https://debbugs.gnu.org/16429#43 presumably still apply.

Message #67 received at 16429 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 16429 <at> debbugs.gnu.org
Subject: Re: bug#16429: EMACSDATA in the MS Windows registry can interfere
 with building
Date: Fri, 20 May 2022 04:15:55 +0200

Glenn Morris <rgm <at> gnu.org> writes:

> 0cbc41322e clearly adds nothing relevant over e088b01d29.
> so the comments from https://debbugs.gnu.org/16429#43 presumably still apply.

This was:

> Fixed for POSIX platforms.
> Leaving open with downgraded severity since the MS Windows registry
> could presumably still be a problem.

Eli, is there something we should do here on Windows hosts, or is
defining these variables in the registry just a user error?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #72 received at 16429-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: rgm <at> gnu.org, 16429-done <at> debbugs.gnu.org
Subject: Re: bug#16429: EMACSDATA in the MS Windows registry can interfere
 with building
Date: Fri, 20 May 2022 17:12:55 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 16429 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> Date: Fri, 20 May 2022 04:15:55 +0200
> 
> Glenn Morris <rgm <at> gnu.org> writes:
> 
> > 0cbc41322e clearly adds nothing relevant over e088b01d29.
> > so the comments from https://debbugs.gnu.org/16429#43 presumably still apply.
> 
> This was:
> 
> > Fixed for POSIX platforms.
> > Leaving open with downgraded severity since the MS Windows registry
> > could presumably still be a problem.
> 
> Eli, is there something we should do here on Windows hosts, or is
> defining these variables in the registry just a user error?

I see no reliable way of avoiding the effect of Registry settings on
incompatible Emacs versions.  People who want to be able to run
different Emacs versions on the same machine, including the capability
of building newer versions, should NOT use the Registry for these
settings.  We modified the addpm installation program some time ago to
not create any Registry settings that didn't already exist for this
very reason.

So I've now updated the Emacs manual with the advice not to use the
Registry, and I'm therefore closing this bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.