From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: akrl--- via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: [feature/native-comp] breakage on build Date: Tue, 02 Feb 2021 09:11:52 +0000 Message-ID: References: <87lfca7lsb.fsf@russet.org.uk> <463a837ca8ddbf7533c403350d75125d@russet.org.uk> <39105f71034e0902a749994dda9c4704@russet.org.uk> <83mtwq8kf3.fsf@gnu.org> <83k0ru8jnx.fsf@gnu.org> <83im7e8icf.fsf@gnu.org> <86ft2fjov2.fsf@gmail.com> Reply-To: Andrea Corallo Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37207"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Andy Moreton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Feb 02 10:12:31 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 1l6rjb-0009Zq-Fb for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Feb 2021 10:12:31 +0100 Original-Received: from localhost ([::1]:38562 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l6rja-0006yO-Ht for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Feb 2021 04:12:30 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34922) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l6rj2-0006Fw-Pv for emacs-devel@gnu.org; Tue, 02 Feb 2021 04:11:56 -0500 Original-Received: from mab.sdf.org ([205.166.94.33]:38880 helo=ma.sdf.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l6rj0-0002LF-Ri for emacs-devel@gnu.org; Tue, 02 Feb 2021 04:11:56 -0500 Original-Received: from akrl by ma.sdf.org with local (Exim 4.92) (envelope-from ) id 1l6riy-0006Ja-GX; Tue, 02 Feb 2021 09:11:52 +0000 In-Reply-To: <86ft2fjov2.fsf@gmail.com> (Andy Moreton's message of "Tue, 02 Feb 2021 00:27:13 +0000") Received-SPF: pass client-ip=205.166.94.33; envelope-from=akrl@sdf.org; helo=ma.sdf.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:263713 Archived-At: Andy Moreton writes: > On Sat 30 Jan 2021, akrl--- via "Emacs development discussions." wrote: > >> Eli Zaretskii writes: >> >>>> Date: Sat, 30 Jan 2021 18:38:10 +0200 >>>> From: Eli Zaretskii >>>> Cc: akrl@sdf.org, emacs-devel@gnu.org >>>> >>>> compiling to >>>> c:/msys64/home/Administrator/emacs-build/build/emacs-28.0.50-snapshot-feature_native-comp-windows/native-lisp/28.0.50-x86_64-w64-mingw32-3459bc949453c7833f94b407f8ee7c17/titdic-cnv-765ac3beca7090ba17f799d9600c18e6-a5dbcc84a969a94717512a079e1cc96a.eln >>>> >>>> The name of that file is suspiciously close to the 260-byte limit of >>>> file-name length that Win32 APIs support. So my guess is that the >>>> temporary file had a few more characters (like the 6 characters which >>>> replace the XXXXXX, perhaps?), and that caused the failure. >>> >>> Btw, Andrea: why do we need no less than 3 32-character hashes in that >>> file name? With 26-byte limit on file names that libgccjit can use, >>> these 96 characters use up almost half of that space, and that will >>> bite us time and again down the road on MS-Windows. Can we use just >>> one hash? >>> >> >> Say ATM we have: >> >> native-lisp/28.0.50-x86_64-w64-mingw32-HASH1/titdic-cnv-HASH2-HASH3.eln >> >> - HASH1 disambiguate triplet, Emacs configuration, version etc. We can >> say this is disambiguating everything that influence the ABI the eln >> expects and exposes. >> >> - HASH2 is just hashing the full patch of the original source file. > > This is unclear. Did you mean the content of the source, or its filename ? Sorry typo; wanted to write path, so please read filename. >> - HASH3 is hashing the content of the file. >> >> HASH1 is handy because one can remove selectively the eln files of say a >> previous Emacs version or an old configuration. I often remove all of >> these folders but the most recent one. That said technically HASH1 and >> HASH3 could be merged. > > This should be done: it is better to simplify the filesystem layout and > provide some utility functions to help with removing stale cache entries. Please design and implement such a system, when will be proved it works well I'm sure these patches will be welcome. >> HASH2 is handy because there must be within this folder at most one file >> with each HASH2. IOW recompiling we remove all the other .eln sharing >> the same HASH2 if present as indeed these files are obsolete. > > So if the same source same rebuilt with different eln compile flags then > only one of them is retained ? No, HASH2 is not influenced by eln compilation flags. Andrea