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: [External] : emacs-28 windows binaries available from alpha Date: Fri, 11 Feb 2022 13:30:21 +0200 Message-ID: <83sfspsks2.fsf@gnu.org> References: <834k5d3hbv.fsf@gnu.org> <83o83l1v51.fsf@gnu.org> <83k0e3vox9.fsf@gnu.org> <83fsoruv2u.fsf@gnu.org> <83o83eudgz.fsf@gnu.org> <83ee4atzh5.fsf@gnu.org> <83v8xlst5p.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22593"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 11 12:33:17 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 1nIUAv-0005eP-Jn for ged-emacs-devel@m.gmane-mx.org; Fri, 11 Feb 2022 12:33:17 +0100 Original-Received: from localhost ([::1]:59588 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nIUAu-0002pa-Cw for ged-emacs-devel@m.gmane-mx.org; Fri, 11 Feb 2022 06:33:16 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:58518) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nIU8A-0007DU-OG for emacs-devel@gnu.org; Fri, 11 Feb 2022 06:30:26 -0500 Original-Received: from [2001:470:142:3::e] (port=59684 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nIU88-0003TG-FY; Fri, 11 Feb 2022 06:30:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=hSHw8BQjcUVwXHteRBob6V6bSYvCZwsSZJOEHauC2o4=; b=lJ21ag04kRwC h67ejmTd/yc1lFI3dTQ18bnvuSkiTSPG9058kJG/5HI2y7/Tcu7FDrvaaX4fQezUq5LWzBsDhWjyc y8ycL0vJl+p0h6bxbCCU6nHOs8Wqc0YdPWAft9Rswx6ajr2thuCHAd+iid69KJFYM3HIWZpcPBspc 6+FrFIXZP+zLPtrSJdQp85iiJwJDrZO+zs7RwMQSCZVYC3+IiwKiX5bzIV86yzQUeuaLEMDUl7cV4 /IF1ilUroGOKAqFdcfmjE53w3fOYNhjCWyDPhG9ojR6JTqJdwaApoIQIWRX9h60jO7sIw/FiFhKKn l7u/4B1b0Zv/UKk26TsUrw==; Original-Received: from [87.69.77.57] (port=2863 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nIU87-0002p4-Sc; Fri, 11 Feb 2022 06:30:24 -0500 In-Reply-To: (message from Andrea Corallo on Fri, 11 Feb 2022 09:16:25 +0000) 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:286162 Archived-At: > From: Andrea Corallo > Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org > Date: Fri, 11 Feb 2022 09:16:25 +0000 > > >> Anyway I was thinking if it wouldn't be correct to emit also a warning > >> if libgccjit is not available. This condition could prevent some > >> package to work as expected (ex evil-mode IIRC) so might be worth to > >> inform the user that and emacs compiled with native-comp is being run > >> without libgccjit being available. > > > > I'm not sure I see the usefulness of such a warning. If Emacs works > > correctly regardless, the warning could annoy. So I tend to think we > > should introduce the warning only if enough users complain that Emacs > > silently does something they'd prefer to know about. > > I think it might be useful for two reasons: > > 1- let the user know that a native compiled Emacs is being run without > access to libgccjit, not only it might not function as expected but > most likely I guess that if the user compiled a native compiled Emacs > he wants to have it working with native code. So in general I guess > it might be informative. This is unlikely to happen if the user has libgccjit installed: if it is found when building Emacs, it will most probably be also found when running it. So the warning will mostly show when the user installed Emacs built by someone else. In which case, the user already made the decision not to install libgccjit, so warning the user about that would be in many/most cases redundant. > 2- help us identifying the issue when a bug is opened because of it, if > we suspect that's the problem we can ask the user to have a look to > the warnings. This could be a valuable indication, but if so, I think it's report-emacs-bug that should detect and report it, as part of the system configuration description, as you suggest. > Another alternative to the problem on MS-Windows would be not to > optimize calls to primitive functions and have them go always through > funcall. This is very easy compiler wise but has probably too drastic > as brings a performance penalty. Right.