From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Moreton Newsgroups: gmane.emacs.devel Subject: Re: attribute warn_unused_result Date: Thu, 03 Feb 2011 22:08:04 +0000 Message-ID: <82d3n8lqkb.fsf@gmail.com> References: <4D4B02EF.1080708@cs.ucla.edu> <7C616374-F2D6-4797-A66C-9C4D293B93B6@mit.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1296771296 11926 80.91.229.12 (3 Feb 2011 22:14:56 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 3 Feb 2011 22:14:56 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 03 23:14:52 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 1Pl7Rx-0000B9-Rv for ged-emacs-devel@m.gmane.org; Thu, 03 Feb 2011 23:14:51 +0100 Original-Received: from localhost ([127.0.0.1]:46999 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pl7Rn-0003uU-MY for ged-emacs-devel@m.gmane.org; Thu, 03 Feb 2011 17:14:39 -0500 Original-Received: from [140.186.70.92] (port=48513 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pl7OM-0001Z4-1s for emacs-devel@gnu.org; Thu, 03 Feb 2011 17:11:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pl7Lv-0000zz-R2 for emacs-devel@gnu.org; Thu, 03 Feb 2011 17:08:36 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:37798) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pl7Lv-0000zk-LU for emacs-devel@gnu.org; Thu, 03 Feb 2011 17:08:35 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Pl7Lq-0004wT-4P for emacs-devel@gnu.org; Thu, 03 Feb 2011 23:08:30 +0100 Original-Received: from 82-69-64-228.dsl.in-addr.zen.co.uk ([82.69.64.228]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 03 Feb 2011 23:08:30 +0100 Original-Received: from andrewjmoreton by 82-69-64-228.dsl.in-addr.zen.co.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 03 Feb 2011 23:08:30 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 38 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 82-69-64-228.dsl.in-addr.zen.co.uk User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (windows-nt) Cancel-Lock: sha1:WUTUcTjgPJHXLLLAZtS3dTkVycw= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 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:135532 Archived-At: On Thu 03 Feb 2011, Chad Brown wrote: > On Feb 3, 2011, at 11:33 AM, Paul Eggert wrote: >> >> Gnulib's ignore-value module is designed for that. I installed the >> following: > > ..and it broke the W32 and nextstep builds (at least) again. > > I appreciate the ideas behind the gnulib inclusion, but it seems to be > causing a lot more broken builds than we saw before. What can we do > to fix this? 1) Prevail upon the developers in question to work in a more consensual style and publicise changes that will break non-POSIX builds *before* installing them. 2) Work on fixing the w32 build system so it is less hand-crafted and makes more use of the POSIX build machinery. Given the number of different environments and toolchains used to build for win32 targets, this is tricky. > I get the general impression via the 50+ message thread about DOS port > compatibility that the gnulib people are mostly unwilling to make > efforts to avoid breaking the emacs build. Is this the case, or are > we simply seeing bad luck? > > So far, the features of gnulib have not seemed to be worth the > trouble. As long as it does not restrict portability of emacs to platforms and toolchains that gnulib want to support then there is a little temporary pain and some longer term benefits. If the two projects have divergent views on which platforms and toolchains to support then that would indeed be a problem. AndyM