From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Corwin Brust Newsgroups: gmane.emacs.devel Subject: Re: [External] : emacs-28 windows binaries available from alpha Date: Fri, 4 Feb 2022 22:35:39 -0600 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39088"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "H. Dieter Wilhelm" , Emacs developers To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Feb 05 05:36:31 2022 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 1nGCoI-0009vU-MC for ged-emacs-devel@m.gmane-mx.org; Sat, 05 Feb 2022 05:36:30 +0100 Original-Received: from localhost ([::1]:60348 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nGCoH-0006Av-7e for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Feb 2022 23:36:29 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:36746) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nGCni-0005Wq-Cq for emacs-devel@gnu.org; Fri, 04 Feb 2022 23:35:54 -0500 Original-Received: from mail-ej1-f44.google.com ([209.85.218.44]:41734) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nGCng-0008Ks-9k for emacs-devel@gnu.org; Fri, 04 Feb 2022 23:35:54 -0500 Original-Received: by mail-ej1-f44.google.com with SMTP id a8so25174715ejc.8 for ; Fri, 04 Feb 2022 20:35:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XRw3cxIouOjJV262CP8pFQ28VtcFomf+DEJ0CTS9D+Q=; b=7FkmkrvehV6to78FpeGSrCavBNhASXeYhafaV/Pmokb2Ed5clPbwzgK9CASFbPQ0i7 wk+WegMvXFIufb1J7+XFsC/E12SB44X8ZWQ/OzMbjU7CpncK5pvqZfNrgvPfr1KVnW9A 6jN62EFPQFdBp9duRwZNqID0J15gzop3y0S2vJIXqF6o55S0RAHWMt9R4Vs41hpQyTmu ZVfW17+d5aA2WXNAJYf5R40FL6o2JorvbMQHoIQKYt93B4+v6VxOei3dtl5G5g4fiOsP PhpkCGDDGIyIEA7+B7jUxRfHYsXoFWSCNJU1DmoBdkTvbwCITO7/12zr6llKr3y/aLAq 421w== X-Gm-Message-State: AOAM533TagWcAIkAoed5JnafN86qoOJlmdzeYBGkbb4atNGMBwmz61TD HbWQOFfiak9cbzaoQNcqP/IZWTl72n+4F+KY5E4= X-Google-Smtp-Source: ABdhPJxCWGsmn49Zl980ZkNkekZq0geNgV0Mvb1uHvUZNYHRnPxeT9otWn03hvv+L94Y7hwXfMQan6RsINgyMUOuMF4= X-Received: by 2002:a17:907:3f97:: with SMTP id hr23mr1752094ejc.578.1644035750741; Fri, 04 Feb 2022 20:35:50 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=209.85.218.44; envelope-from=mplscorwin@gmail.com; helo=mail-ej1-f44.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:285883 Archived-At: On Fri, Feb 4, 2022 at 7:29 PM Drew Adams wrote: > > Just to confirm: > > 1. does the machine where this occurs have MSYS including libgccjib > > and gcc, and if so > > No idea, but most likely not. It's not a software > development laptop. No gcc or other C compiler, > for sure. Than it is indeed a mystery why we are getting an error related to not finding libgccjib. As best we expect (and to the extent of my still fairly limited understanding, it is true that) ... [this sentence will be right back, after after these further inline quotations] > > > 2. is bin folder of that MSYS installation on your path? > > No MSYS, most likely. > > > As I strongly suspect you know: We aren't providing libgccjib+gcc with > > the Emacs 28 distributions, at least we haven't decided to do that so > > far. > > No, I don't know. And I don't know what libgccjib+gcc > is, or why I would want or need it on my laptop. ... we do not need to have MSYS, much less libgccjit, to use an Emacs binary that has been compiled with support for native compilation. Natively compiling additional ELN won't be possible and shouldn't be attempted in that case. That said, when MSYS (or GCC or libgccjit) isn't installed (or isn't on the path when we start Emacs, even so the (currently very few) ELN files provided with the release should work. In my testing this has held true. > > I also don't understand, if Emacs native compiling > tries to use existing *.elc files, why it doesn't > fall back to using the *.el, if trying to compile > natively from the *.elc raises an error. I'm fairly sure Emacs is not (at least, should not be) trying to execute native compilation. > > IOW, in the case of this small Elisp file, why would > Emacs depend on using a *.elc if present, and simply > give up if trying to use it raises an error. The > source of truth is (should be) *.el, not *.elc. That sounds like a feature request to me: [wishlist] When an error occurs loading the ELC, attempt loading from the EL file (given the EL file is present locally). Note, I didn't do any research to see if this could already be supported [[Hope the capitalized file-extentions aren't making this --even-- harder to parse. I find them easier to read in the midst of human facing text vs seeing short not-actual-words in the same places. Let me know if that's offputting.]] > > I can maybe understand that starting with a *.elc > might be a useful shortcut of some kind, but why > should an error with a *.elc - especially of the > sort that some compiling tool etc. isn't available > - prohibit using an Emacs binary? Since when > should an Emacs binary depend on such things? > An ELC file, when present, is considered the primary "machine readable" source for the feature, wnless the corresponding ELN exists in which case it is. More on this further down. I was assuming you tried to use your elc intententioonaly as a way to test the new binaries, and that you have good reason to expect that to work. For myself (in terms of my own use of Emacs), I keep separate package repository (ELPA) folders for each installed version of Emacs. I thought that was required, at least in as much as I want to be able to (e.g.) run Emacs 27 sometimes, but I don'tt want errors from packages that may have been compiled with Emacs 28 or snapshot builds. I treat my ELC files as disposable but take care these days to hang on to my EL files, and go to pains to fetch (and usually byte-compile) them during startup when they aren't around. That's a bit of a different use-case, tho, I believe. Can you confirm it is expected that byte-complied files are promised to be forward compatible? This is outside my experience. AFAIK, from the Emacs developer perspective, the "most compiled" form of an elisp package becomes it's "machine readable feature" file and, as such, that should be the only version which is technically needed for Emacs to support what functionality it provides. So, in the case of an ELC being present, removing the EL file completely should be harmless: it is essentially documentation and ought to safe to remove when the user/distro doesn't want it. In point of fact, I can't remember reading about whether it's safe for end-users (or distros) to remove an ELC when using/shipping an ELN for the feature. > If it's no longer possible to use a Windows binary > unless you have such development tools installed, > then Emacs 28 and later will be useless, for me at > least. Fortunately, this is not the case. Neither by intention nor (so far in my own testing) in fact. > > > Appreciate the backtrace; I'll reply again when > > I can attempt testing in a sans-MSYS environment. > > I take that as a hopeful sign that the _intention_ > is not to require dev tools such as gcc, msys etc. > to be present on the machine where I use an Emacs > binary. That's quite correct, thus my troubling two of my kiddos for use that mostly run Minecraft and block-vader, or whatever it is. On one I have added MSYS, on the other not. > > If that's the intention then great, and I wish you > good luck getting past this hurdle. Sorry to be > the bearer of the bad news that there are some > Emacs users who don't use software dev tools. > That's no news at all., At my day-job (generally speaking) I am one of them :) > Maybe that will ultimately mean that such users > must forego being able to use natively compiled > code? If so, that's OK by me - no worse than before. I hope not. As far as I've seen when testing without MSYS, Emacs is able to load and utilize ELN files even when MSYS isn't available. (Although it can't create/update any ELN files, notwithstanding your experience, I haven't found any place where it errors out because, e.g. libgccjit is missing.) > > It's likely that some of what I just wrote betrays > false assumptions or misunderstandings on my part. > I haven't been following the attempt to provide > native compilation. I think (hope) so, yes. I've done my best to speak directly to these but let me know where I may have failed. To summarize my own understanding/expecations: - Emacs works fine when MSYS isn't around - Nattive Comp is only available when MSYS is around - ELN files are created only when Native Comp is available - ELN files are preferred when they are present - ELC files are used when no ELN exists - EL files are used only when no ELC exists - We are warned loading an ELC newer than it's EL - Likewise when loading an ELN newer than it's ELC I hope and trust that you will LMK if anything I've said suggests what you are trying may not be supported (and likewise for anything seeminly untrue or very unexpected in what I've said). Corwin