From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [feature/native-comp] breakage on build Date: Fri, 05 Feb 2021 13:50:29 +0200 Message-ID: <83k0rmpwca.fsf@gnu.org> References: <87lfca7lsb.fsf@russet.org.uk> <39105f71034e0902a749994dda9c4704@russet.org.uk> <83mtwq8kf3.fsf@gnu.org> <83k0ru8jnx.fsf@gnu.org> <83im7e8icf.fsf@gnu.org> <838s8a8adr.fsf@gnu.org> <83sg6h6s6d.fsf@gnu.org> <8335yf7qtf.fsf@gnu.org> <831rdy5i2r.fsf@gnu.org> <87y2g5p0q8.fsf@russet.org.uk> <87im7799s9.fsf@russet.org.uk> <83o8gzrgsi.fsf@gnu.org> <87eehv7ru1.fsf@russet.org.uk> <83ft2brebq.fsf@gnu.org> <87lfc3mvi1.fsf@telefonica.net> <834kirr2b2.fsf@gnu.org> <87a6sjmqpc.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13399"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 05 12:52:05 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l7zee-0003NA-7N for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Feb 2021 12:52:04 +0100 Original-Received: from localhost ([::1]:48902 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l7zed-000502-9C for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Feb 2021 06:52:03 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36080) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l7zdB-0003xb-If for emacs-devel@gnu.org; Fri, 05 Feb 2021 06:50:33 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36996) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l7zdA-0000DB-M9; Fri, 05 Feb 2021 06:50:32 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3691 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1l7zd3-00085c-Kb; Fri, 05 Feb 2021 06:50:31 -0500 In-Reply-To: <87a6sjmqpc.fsf@telefonica.net> (message from =?iso-8859-1?Q?=D3scar?= Fuentes on Thu, 04 Feb 2021 23:08:15 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:263976 Archived-At: > From: Óscar Fuentes > Date: Thu, 04 Feb 2021 23:08:15 +0100 > > >> This would be problematic. In general, applications that put things on > >> PATH (or modify PATH in general) are frowned upon by many power users, > >> for good reasons. > > > > Do you have any alternative suggestion that won't be frowned upon? > > Then please describe it. > > Put all binaries on the same directory as emacs.exe/runemacs.exe That won't work, not in general: searching executables doesn't consider the directory from which the program was invoked, it only considers the current working directory. > except > probably those which are executed by a driver and that driver expects > them to be on certain path relative to the driver's path (AFAIK gcc.exe > does that, dunno about libgccjit.dll (or whatever its name is)). All of GCC does that. Which means people who have a full development environment installed will now need to have two copies of it, at least potentially, unless they configure their directories in a very specific manner. I don't see how this is better in general than telling people to put stuff on PATH. > > And if you think Emacs shouldn't put things on PATH, then what should > > we do with what we already put there (runemacs.exe, emacsclient.exe, > > addpm.exe, etags.exe, and a few others)? > > My Emacs installs on Windows never required to touch PATH. Now that I > use Emacs from the MSYS2/MinGW-w64 environment (which means that > runemacs.exe is executed from the mingw64/bin directory) PATH and > exec-path are modified by my emacs.el but, outside of Emacs, PATH is > unaltered (it contains nothing related to MSYS2/MinGW-w64). > > It is true that currently the user must modify exec-path to run > executables that exist on the same directory as emacs.exe (when executed > from a Windows shortcut, not from a MSYS2/Mingw-w64 shell), but that is > a burden that we can solve. This arrangement evidently works for you, but it doesn't mean it is the best one. For example, AFAIU it generally doesn't allow invoking the commands outside of Emacs. I don't think it's a good idea to have all those useful programs ghettoized to work only from Emacs, because Emacs is just one tool in the user's tool-chest.