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: Native compilation on as default? Date: Thu, 26 Oct 2023 10:13:56 +0300 Message-ID: <83pm11hn4b.fsf@gnu.org> References: <83legs281v.fsf@gnu.org> <83r0liiy44.fsf@gnu.org> <87a5s66o2w.fsf@web.de> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31240"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acorallo@gnu.org, stefankangas@gmail.com, emacs-devel@gnu.org To: "Dr. Arne Babenhauserheide" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 26 09:14:33 2023 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 1qvuZd-0007x2-Km for ged-emacs-devel@m.gmane-mx.org; Thu, 26 Oct 2023 09:14:33 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qvuYz-00011U-Jn; Thu, 26 Oct 2023 03:13:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qvuYw-0000xu-Bi for emacs-devel@gnu.org; Thu, 26 Oct 2023 03:13:50 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qvuYv-0002LJ-R7; Thu, 26 Oct 2023 03:13:49 -0400 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=1vhZVIKyMz8ZDZGyn4WooA7vSKNhcWKVPPynoND1Jnw=; b=lWjn4Q4rU5kx Uj5aLHfcCz4LJ+1TWu96eLiunIdprT8zN+K/31CApfJ3aWiFvSqhPZCEd0jjOR07ukcB/+m0km2UA 6++Q6QuPXAGaxHAzyUsfksCZ9JalxA35vKrcFvPxAIiKTXjqWQy2w6nMt7cGPZKHHebAXrMj4Gyu0 DAm5IzEor6DbIfvcFu5WR/wDFTjvz4HJjWEuKePMJE+BNo/DqjwF6diFaj+WYsuIJVINpTWQoVsug 9D+iKI4pM9BkPc261Pt5/zVy2gSq7Vkilf/qOOupHCk27m0Q6XdyIzRTpp8RVXM+ALbmdTmPD8anu xThFTvwqXRc4Wg3mG5vM/Q==; In-Reply-To: <87a5s66o2w.fsf@web.de> (arne_bab@web.de) 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:311888 Archived-At: > From: "Dr. Arne Babenhauserheide" > Cc: Stefan Kangas , Eli Zaretskii , > emacs-devel@gnu.org > Date: Thu, 26 Oct 2023 05:47:15 +0200 > > Andrea Corallo writes: > > > As asynchronous native compilation always starts from a pristine > > environment, it is more sensitive to such omissions, and might be > > unable to compile such Lisp source files correctly. > > " > > > > Essentially if in Emacs one has for any reason the definition of the > > macro loaded before invoking the byte-compiler, this will not complain > > even if the require is missing. > > Does this mean that previously working Emacs packages or setups may be > broken with native compilation? I don't see how the text above could be interpreted to mean that some package will be "broken". A warning about some symbol being unknown, or its function slot being void, never prevents Emacs from emitting valid code, which will DTRT if that symbol or function are known at run time. This whole sub-thread is about _warnings_ emitted by async compilation, which annoy some people, that's all. Nothing will ever become "broken" due to a warning, unless it was already broken to begin with. > Or only that such packages would not get the speed-boost from native > compilation? Not even that. Only if the native compilation _errors_out_, you will get the lack of speed-boost, because the .eln file will not be written.