From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Copley Newsgroups: gmane.emacs.bugs Subject: bug#14513: 24.3.50; Site load-path pieces differ in MSYS build Date: Tue, 4 Jun 2013 21:14:10 +0100 Message-ID: References: <83y5aw4e0x.fsf@gnu.org> <83r4go49dg.fsf@gnu.org> <83hahk467a.fsf@gnu.org> <83ehco42t6.fsf@gnu.org> <837gif4qni.fsf@gnu.org> <83r4gn2xhk.fsf@gnu.org> <838v2t23c5.fsf@gnu.org> <8361xx20lb.fsf@gnu.org> <838v2pwtu5.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e016353ce65497704de59b997 X-Trace: ger.gmane.org 1370376920 4249 80.91.229.3 (4 Jun 2013 20:15:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Jun 2013 20:15:20 +0000 (UTC) Cc: 14513@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jun 04 22:15:20 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UjxdV-0005Vl-HA for geb-bug-gnu-emacs@m.gmane.org; Tue, 04 Jun 2013 22:15:17 +0200 Original-Received: from localhost ([::1]:54935 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UjxdU-0007Io-Qn for geb-bug-gnu-emacs@m.gmane.org; Tue, 04 Jun 2013 16:15:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49466) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UjxdM-0007HD-UT for bug-gnu-emacs@gnu.org; Tue, 04 Jun 2013 16:15:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UjxdH-0002og-Gu for bug-gnu-emacs@gnu.org; Tue, 04 Jun 2013 16:15:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34327) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UjxdH-0002mw-9n for bug-gnu-emacs@gnu.org; Tue, 04 Jun 2013 16:15:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UjxfC-0006Ds-Ab for bug-gnu-emacs@gnu.org; Tue, 04 Jun 2013 16:17:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Richard Copley Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 04 Jun 2013 20:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14513 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 14513-submit@debbugs.gnu.org id=B14513.137037697923766 (code B ref 14513); Tue, 04 Jun 2013 20:17:02 +0000 Original-Received: (at 14513) by debbugs.gnu.org; 4 Jun 2013 20:16:19 +0000 Original-Received: from localhost ([127.0.0.1]:50918 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UjxeU-0006BH-Km for submit@debbugs.gnu.org; Tue, 04 Jun 2013 16:16:19 -0400 Original-Received: from mail-ea0-f179.google.com ([209.85.215.179]:59659) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UjxeS-0006Az-8s for 14513@debbugs.gnu.org; Tue, 04 Jun 2013 16:16:17 -0400 Original-Received: by mail-ea0-f179.google.com with SMTP id z16so562257ead.10 for <14513@debbugs.gnu.org>; Tue, 04 Jun 2013 13:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EDuPK9aafKZyApKTOIG8d+tHH7UNFX+FZ31nYP6whEU=; b=WVVPhwPyNRr9gLEPfEAQjRIupHeIeSk425S00FSSwclfE2ObaxK5fc5Wkmmyw4v/9/ +OBYmcEu6Tut4koL/NDTyzUzhapaFbafgoO3+9EAxIK+1zz3bOoZXCUmTw16tyqv5UC4 RODNdBcnxFk31Z+xNfzA1owh9+dWaBdD8RA0FgxxSUEFWEG+YJpyc7K4OJImZPqIt1qj 39AbaWSSGQKQLtIvXd6tDjpoBnqrfkaktv1UrFTzZX6ZmdYeCZAT8Qgl3D/SDwFb/Rqr esravaRu/s19SGfGM5GNNg0USG9pasIY5y5zoBrq1UhFQksuIHBb2kLhhZbCIBRDuV5e tY1Q== X-Received: by 10.15.36.72 with SMTP id h48mr9866533eev.33.1370376850711; Tue, 04 Jun 2013 13:14:10 -0700 (PDT) Original-Received: by 10.14.212.67 with HTTP; Tue, 4 Jun 2013 13:14:10 -0700 (PDT) In-Reply-To: <838v2pwtu5.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:74807 Archived-At: --089e016353ce65497704de59b997 Content-Type: text/plain; charset=ISO-8859-1 On 4 June 2013 20:37, Eli Zaretskii wrote: > > Date: Tue, 4 Jun 2013 19:27:50 +0100 > > From: Richard Copley > > > > 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? --089e016353ce65497704de59b997 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 4= June 2013 20:37, Eli Zaretskii <eliz@gnu.org> wrote:
> Date: Tue, 4 Jun 2013 19:27:50 +0100
> From: Richard Copley <rcopley@= gmail.com>
>
> One last time I'll advocate the change I was thi= nking of initially: re-add
> the "ROOT/../site-lisp" entry to PATH_SITELOADSEARCH in epat= hs.nt, as in
> the attached patch.

I hear you, but please understand: it's not just addition of a directory to the variable. =A0These directories are tested for existence at startup, and Emacs displays a warning of any of them doesn't exist.<= br> 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. =A0And 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. =A0If 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?

--089e016353ce65497704de59b997--