From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Annoyingly cautious make rules Date: Fri, 02 Dec 2011 12:21:54 -0800 Message-ID: <4ED93362.30309@cs.ucla.edu> References: <83ehwnc97k.fsf@gnu.org> <4ED917E2.7020807@cs.ucla.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1322857551 9012 80.91.229.12 (2 Dec 2011 20:25:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 2 Dec 2011 20:25:51 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org, Andreas Schwab , Stefan Monnier , rms@gnu.org To: Glenn Morris Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 02 21:25:47 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RWZg2-0005U8-Er for ged-emacs-devel@m.gmane.org; Fri, 02 Dec 2011 21:25:46 +0100 Original-Received: from localhost ([::1]:49111 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWZfm-0007gp-U7 for ged-emacs-devel@m.gmane.org; Fri, 02 Dec 2011 15:25:30 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:37050) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWZfk-0007dl-2X for emacs-devel@gnu.org; Fri, 02 Dec 2011 15:25:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RWZfH-00084L-08 for emacs-devel@gnu.org; Fri, 02 Dec 2011 15:25:17 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:50223) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWZeG-0007pj-QV; Fri, 02 Dec 2011 15:23:57 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 457CE39E8006; Fri, 2 Dec 2011 12:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiMrNMF0IKWg; Fri, 2 Dec 2011 12:22:02 -0800 (PST) Original-Received: from [131.179.210.47] (Cs-210-47.CS.UCLA.EDU [131.179.210.47]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 6089B39E800A; Fri, 2 Dec 2011 12:22:02 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 131.179.128.62 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:146439 Archived-At: On 12/02/2011 10:39 AM, Glenn Morris wrote: > I suggest that those of you who find configure too slow and who know what > you are doing disable maintainer mode in your personal copies Even if it is a good idea to enable these problematic dependencies by default, surely there's no question that "maintainer mode" (whatever we decide it to be) should not be the default. Maintainer mode should cater to experts, not to casual and unskilled builders, and it's pretty confusing to say (as we do now) that you should disable maintainer mode only if you're an expert and you know what you're doing. In other words, if we stick with the 2011-03-20 change to enable the dependencies by default, --enable-maintainer-mode should *disable* those dependencies. > I believe the default build rules ought to be what is most correct, not > what is mostly correct but fast, since the latter can lead to confusing > errors for people who are not familiar with all the details. We agree about this, but the disagreement is over whether these problematic dependencies are more "correct". In an environment where Autoconf isn't installed, or is the wrong version (or similarly for m4, Automake, etc.), these problematic dependencies are more likely to cause problems than to cure them. For example, there are plausible use cases where a naive builder copies files around and then gets stuck because an unnecessary autoconf invocation fails. So there's a good case to be made that it's more "correct" (for the casual, unskilled builder) to omit these dependencies, as we did before 2011-03-20.