From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] [WIP] Port feature/native-comp to Windows. Date: Mon, 11 May 2020 19:19:01 +0300 Message-ID: <83eerqbg22.fsf@gnu.org> References: <5eb5b953.1c69fb81.a67ce.a764@mx.google.com> <83lfm1hc91.fsf@gnu.org> <83wo5lds87.fsf@gnu.org> <83lflzd8es.fsf@gnu.org> <83ftc7d4zu.fsf@gnu.org> <83blmvd2if.fsf@gnu.org> <833686d08r.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="21915"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, akrl@sdf.org To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 11 18:21:12 2020 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 1jYBB2-0005Wp-4R for ged-emacs-devel@m.gmane-mx.org; Mon, 11 May 2020 18:21:12 +0200 Original-Received: from localhost ([::1]:55836 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYBB1-00089o-01 for ged-emacs-devel@m.gmane-mx.org; Mon, 11 May 2020 12:21:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51120) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jYB93-0005vJ-5v for emacs-devel@gnu.org; Mon, 11 May 2020 12:19:09 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40045) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYB92-0003tp-52; Mon, 11 May 2020 12:19:08 -0400 Original-Received: from [176.228.60.248] (port=1058 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jYB8z-0000to-Kx; Mon, 11 May 2020 12:19:06 -0400 In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Mon, 11 May 2020 12:20:36 -0300) 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:249812 Archived-At: > From: Nicolas Bértolo > Date: Mon, 11 May 2020 12:20:36 -0300 > Cc: Andrea Corallo , emacs-devel@gnu.org > > > I don't think it would be wise for us to distribute libgccjit, because > > then we'd need to distribute the GCC sources, and the user will be > > unable to reliably use the shipped libgccjit with their local GCC > > installation (due to possible version mismatch). > > IMHO that is really inconvenient from the point of view of a user that just > wants to install Emacs and use all its features. Not "all" of its features, just one. And yes, this is an inconvenience, but it isn't specific to MS-Windows. AFAIK, Posix systems nowadays come without a compiler preinstalled, and you need to install it if you want that. This is a price to pay for compiling to native code using an external compiler. there's no way around this, I think. People who cannot afford installing a working compiler and Binutils will have to give up compiling Lisp files to native code (the Lisp files that come with Emacs can still be provided as *.eln, I would hope). > Installing Mingw is not a simple process (at least in my experience). And adding > it to PATH will also add many other unrelated utilities. This pollutes the PATH > variable and may cause trouble. I haven't done in my machine because I fear it > may interact with badly with the rest of the system. I do have GCC and Binutils on PATH, and I have yet to see any problem. But of course, someone else might feel uncomfortable with that. > I can think of two ways: > > - The whole system will have the mingw libraries available in the LoadLibrary() > search path. Why is that a problem? The number of DLLs is quite small and their names don't conflict with Windows system DLLs. > - The mingw distribution comes with many utilities that the user may not want in > PATH. I don't think I understand what utilities you have in mind. Please name them. > I haven't explicitly installed any of these, but they are in the same > folder as `gcc`: ImageMagick, Python, sqlite, TCL. I don't know why you have them or which package they came with, but they are definitely not needed for running the compiler to produce programs. > Overall I don't think it is a good idea to make the user install a whole Mingw > distribution when they only need 10 files. I really don't see any way around this, sorry. > I can think of a middle-ground solution. Let's have a `comp-gcc-path` variable > that is prepended to PATH in `process-environment` when launching the > compilation subprocess. This will variable should point to the path > where `gcc` lives. > In my system it would be "C:/msys64/mingw64/bin". > > This would set up the environment libgccjit expects (no "-B" flag necessary), > but it would not require adding that directory to PATH. It separates what is > necessary for Emacs to work, from the environment the user setup to work. This only solves the problem of having the stuff on PATH, it doesn't solve the problem of installing it. And it creates a new problem: the DLLs will not be in a place where the system looks for them, so we will need some extra code in the *.eln loader to find them. > As an example: imagine the user prepends a "C:/myproject/custom-gcc/bin" to PATH > and then starts Emacs because they need a customized GCC to work on a certain > project. Let's say they need a custom libgccjit for that project too. Emacs > would load that version because it is first in PATH, and then what may happen is > unpredictable. It may have different function signatures and when Emacs calls > them through dlsym() we would get a hard-to-find crash. This can happen even without this. Users who have more than one compiler installation need to be very careful and need to know what they are doing. > > Right, I think at least on MS-Windows we need to do that. On Posix > > platforms, Emacs will be able to start if there's no libgccjit (and > > will crash if it attempts to call any of its functions), so it might > > be a good idea to use dlopen/dlsym there as well. But on Windows it > > is IMO critical. > > I will do this. Thanks.