From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: windows build failure Date: Tue, 22 Feb 2011 05:49:41 -0500 Message-ID: References: <8739nhji0d.fsf@gmail.com> <4D62C1A3.2050407@cs.ucla.edu> <834o7xt985.fsf@gnu.org> <4D631AC3.3010600@cs.ucla.edu> <4D638488.50101@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1298371801 28799 80.91.229.12 (22 Feb 2011 10:50:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 22 Feb 2011 10:50:01 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 22 11:49:55 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PrpoU-0006Ad-Jl for ged-emacs-devel@m.gmane.org; Tue, 22 Feb 2011 11:49:50 +0100 Original-Received: from localhost ([127.0.0.1]:51517 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PrpoS-0006C7-F2 for ged-emacs-devel@m.gmane.org; Tue, 22 Feb 2011 05:49:48 -0500 Original-Received: from [140.186.70.92] (port=50744 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PrpoO-0006C1-6H for emacs-devel@gnu.org; Tue, 22 Feb 2011 05:49:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PrpoM-0002MU-EK for emacs-devel@gnu.org; Tue, 22 Feb 2011 05:49:43 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:32789) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PrpoM-0002MQ-Ck for emacs-devel@gnu.org; Tue, 22 Feb 2011 05:49:42 -0500 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1PrpoL-0003V4-Gv; Tue, 22 Feb 2011 05:49:41 -0500 In-reply-to: <4D638488.50101@cs.ucla.edu> (message from Paul Eggert on Tue, 22 Feb 2011 01:40:24 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:136370 Archived-At: > Date: Tue, 22 Feb 2011 01:40:24 -0800 > From: Paul Eggert > CC: emacs-devel@gnu.org > > On 02/22/2011 12:57 AM, Eli Zaretskii wrote: > > the artificial definition to zero in sys_stat.in.h > > is only fine if one ignores the de-facto practice of testing for > > S_IFLNK or S_ISLNK to guard code elsewhere that cannot be compiled or > > run on platforms without symlinks > > No, the idea is that normal code should not use #ifdef S_IFLNK. Well, "normal code" in Emacs does. We have 5 such places at this time, if I didn't miss any. > It should instead use "if (S_ISLNK (...)) ...". > On hosts that don't have symbolic links, this "if" > gets optimized away to nothing, so it's just as fast > as the #ifdef. How can we use this idea, when the code in question calls functions like `symlink' or `readlink", which don't exist on hosts that don't support symlinks? This won't link, unless we do something else in addition. If we want to go your way, we need to decide how to resolve this difficulty (and do it in a way that won't become broken when you resync with gnulib an hour or a day or a year from now ;-). > Using plain "if" tends to lead to code that is easier to maintain > than using "#ifdef", in cases like these. I have no issues with using "if", but we must decide how to do that without breaking compilation/link. Once compilation and link work, we will also need to carefully review the affected code, because its logic might subtly assume something about the underlying platforms' behavior wrt symlinks, and that logic might do The Wrong Thing when applied to hosts without symlinks, in the parts that are common to "if" and its "else". > Large chunks of GNU code have been written using this style, > in programs such as coreutils, and it typically works well. For some value of "well". I really don't want to begin griping about the MinGW port of Coreutils on Windows (that's OT here, anyway), but for starters, it is linked against a ported glibc, which includes a bastard semi-broken emulation of symlinks. So I'm not sure anyone has ever tested this approach in practice, at least not in Coreutils. Again, I'm not against going the "if" path, I just wanted to (a) point out the issue and hear from the relevant parties what, if anything, they prefer to do about that, and (b) make sure we all understand that fixing it cleanly is not a trivial job (but not rocket science, either, of course). Once the decision is made, I will be more than willing to contribute to this effort.