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: gnulib strftime imported into Emacs Date: Mon, 31 Jan 2011 06:00:14 +0200 Message-ID: <83r5btg1td.fsf@gnu.org> References: <4D45F788.1020101@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1296446541 15610 80.91.229.12 (31 Jan 2011 04:02:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 31 Jan 2011 04:02:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 31 05:02:17 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 1PjkxF-0007dw-Qx for ged-emacs-devel@m.gmane.org; Mon, 31 Jan 2011 05:02:13 +0100 Original-Received: from localhost ([127.0.0.1]:53266 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PjkwC-0006t6-Mr for ged-emacs-devel@m.gmane.org; Sun, 30 Jan 2011 23:00:24 -0500 Original-Received: from [140.186.70.92] (port=37323 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pjkw8-0006s9-4F for emacs-devel@gnu.org; Sun, 30 Jan 2011 23:00:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pjkw5-00022U-BF for emacs-devel@gnu.org; Sun, 30 Jan 2011 23:00:18 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:41122) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pjkw5-00022I-3o for emacs-devel@gnu.org; Sun, 30 Jan 2011 23:00:17 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LFV00500CCZBL00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Mon, 31 Jan 2011 06:00:15 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.127.81.126]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LFV005G2CGD6M40@a-mtaout23.012.net.il>; Mon, 31 Jan 2011 06:00:15 +0200 (IST) In-reply-to: <4D45F788.1020101@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.175 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:135264 Archived-At: > Date: Sun, 30 Jan 2011 15:43:04 -0800 > From: Paul Eggert > > OK, since the Windows build works with the other gnulib modules, > it's time to try the next one on the list, namely strftime. > I committed to the trunk the following, which migrates Emacs to use > an up-to-date strftime. This will let us add support for > higher-resolution time stamps in format-time-string, among > other things. In the patch quoted below, I omit the automatically > generated files. > > For Windows I expect that HAVE_STDBOOL_H and HAVE__BOOL should > be 1 in config.h. You no longer need to worry about HAVE_STRFTIME. > Also, the build procedure needs to be modified to take into account > the fact that strftime.c is now in lib, not in src. > > I don't see any major problems here, but I'm not a Windows expert. One major problem is that the Windows build is broken again, and will probably remain broken till the next weekend, because I don't think I'll have time to work on this until then. (Volunteers are welcome to beat me to it, but the experience of the last week shows they don't.) It also means that Tom will have to wait for yet another week with his threading related changes, at least that's what I'm asking. Could we please talk before making such disruptive changes in the future? Ideally, Windows related changes should be committed to the repository at approximately the same time as the changes for Posix platforms, but that's only possible if you let me see the changes _before_ they are committed, and if we coordinate the commit to happen when I have time to work on that. Is such cooperation possible?