GNU bug report logs - #14513
24.3.50; Site load-path pieces differ in MSYS build

Previous Next

Package: emacs;

Reported by: Richard Copley <rcopley <at> gmail.com>

Date: Thu, 30 May 2013 13:49:02 UTC

Severity: wishlist

Merged with 14514

Found in version 24.3.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 14513 <at> debbugs.gnu.org
Subject: bug#14513: 24.3.50; Site load-path pieces differ in MSYS build
Date: Tue, 4 Jun 2013 21:14:10 +0100
[Message part 1 (text/plain, inline)]
On 4 June 2013 20:37, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Tue, 4 Jun 2013 19:27:50 +0100
> > From: Richard Copley <rcopley <at> gmail.com>
> >
> > One last time I'll advocate the change I was thinking of initially:
> re-add
> > the "ROOT/../site-lisp" entry to PATH_SITELOADSEARCH in epaths.nt, as in
> > the attached patch.
>
> I hear you, but please understand: it's not just addition of a
> directory to the variable.  These directories are tested for existence
> at startup, and Emacs displays a warning of any of them doesn't exist.
> So, if the Windows build had a directory that other builds don't, we
> would need Windows-specific code to ignore this specific directory if
> it doesn't exist, or make sure it is created -- only on Windows -- at
> "make install" time.  And since this list of directories is
> constructed in a very convoluted way, paying attention to
> EMACSLOADPATH in the environment and to whether Emacs is run
> uninstalled, it is not easy to identify that single directory and
> ignore it.
>
> All this flies in the face of the main reason why I made the MSYS
> build happen: remove as much Windows specific issues, code, and
> configury, so that other developers and maintainers could understand
> how the Windows port is built, and could make changes without fear
> they break the Windows port too easily.  If we don't stick to this
> attitude, the Windows port is in real danger of falling by the wayside
> at the slightest change of fortunes.
>

Okay, I can swallow that, thanks for the explanation.

Would it be doable and generally useful to take account of an
EMACSSITELOADPATH environment variable, on all platforms?
[Message part 2 (text/html, inline)]

This bug report was last modified 12 years and 45 days ago.

Previous Next


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