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: Sat, 30 Jan 2021 19:44:56 +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> 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="14462"; 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, phillip.lord@russet.org.uk To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 30 20:45:56 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 1l5wBw-0003gS-Jd for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Jan 2021 20:45:56 +0100 Original-Received: from localhost ([::1]:55880 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l5wBv-0004jE-Lk for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Jan 2021 14:45:55 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59798) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l5wB4-0004I8-8n for emacs-devel@gnu.org; Sat, 30 Jan 2021 14:45:02 -0500 Original-Received: from mab.sdf.org ([205.166.94.33]:47390 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 1l5wB2-00088m-6r; Sat, 30 Jan 2021 14:45:02 -0500 Original-Received: from akrl by ma.sdf.org with local (Exim 4.92) (envelope-from ) id 1l5wAy-00087N-Ro; Sat, 30 Jan 2021 19:44:56 +0000 In-Reply-To: <83im7e8icf.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 30 Jan 2021 19:06:40 +0200") 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:263635 Archived-At: 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. - 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. 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. The lenght of these hashes is coming directly from the algo we use (md5), I think collision is really not an issue so we can easlily short these. Andrea