From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jim Meyering Newsgroups: gmane.emacs.devel Subject: Re: Change to bzr build instructions Date: Tue, 22 Mar 2011 09:08:32 +0100 Message-ID: <87wrjrinlr.fsf@rho.meyering.net> References: <30r5a1s4kt.fsf@fencepost.gnu.org> <7paagnaam5.fsf@fencepost.gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1300781789 26212 80.91.229.12 (22 Mar 2011 08:16:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 22 Mar 2011 08:16:29 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Glenn Morris Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 22 09:16:24 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 1Q1wlL-0005Fd-Cw for ged-emacs-devel@m.gmane.org; Tue, 22 Mar 2011 09:16:23 +0100 Original-Received: from localhost ([127.0.0.1]:35384 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q1wlI-0000RX-N8 for ged-emacs-devel@m.gmane.org; Tue, 22 Mar 2011 04:16:21 -0400 Original-Received: from [140.186.70.92] (port=60712 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q1wdm-0006K6-TX for emacs-devel@gnu.org; Tue, 22 Mar 2011 04:08:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q1wdl-00054j-JG for emacs-devel@gnu.org; Tue, 22 Mar 2011 04:08:34 -0400 Original-Received: from mx.meyering.net ([82.230.74.64]:36549) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q1wdl-00054V-Aq; Tue, 22 Mar 2011 04:08:33 -0400 Original-Received: by rho.meyering.net (Acme Bit-Twister, from userid 1000) id 36885600DA; Tue, 22 Mar 2011 09:08:32 +0100 (CET) In-Reply-To: <7paagnaam5.fsf@fencepost.gnu.org> (Glenn Morris's message of "Tue, 22 Mar 2011 03:16:18 -0400") Original-Lines: 62 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 82.230.74.64 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:137517 Archived-At: Glenn Morris wrote: >>>> So we should either be more careful about such dependencies in >>>> copy_autogen, or maybe try and get copy_autogen to set >>>> "enable-maintainer-mode=off". >>> I suppose it could do something like that, but I don't know if it is a >>> good idea. I really don't recommend the use of the copy_autogen script >>> at all, except very much as a last resort, so I wouldn't want to see it >>> get too fancy. >> >> I don't think we want to get too fancy, indeed. The `touch' trick seems >> sufficient for now. > > To elaborate, if the autogen/configure script is one with > maintainer-mode = off by default, then if someone uses it, they won't > get any prompting to update configure if configure.in changes in the > repository. At least with the current situation, they will get an error > about missing autotools, which will hopefully prompt them to run > copy_autogen again. > > > On this subject, what to do about maintainer-mode in releases? > At present, I put a note in admin/make-tarball.txt saying that the > configure in a release tarfile should be generated with maintainer-mode > off. > > i) It's rather poor to have to remember to change that. > > ii) Is it actually necessary to make such a distinction? > If configure.in etc are not changed, it does not matter, and if someone > does edit configure.in, arguably they _should_ get an updated configure. > This seems to be what automake recommends now: > > http://www.gnu.org/s/hello/manual/automake/maintainer_002dmode.html Yes. > (or is it actually recommending removing the option altogether, and > having it always on?) It is recommending never to use the AM_MAINTAINER_MODE macro, and explains how its use can cause trouble. When you don't use the macro, that is like making configure always use --enable-maintainer-mode. Very early on (like right after adding it), I found that maintainer mode was causing more problems than it solved. Now, with complete and robust auto*-running rules in nearly all Makefiles (in the early years, that was actually a problem) and relatively modern and compatible autoconf and automake, I find that there is little need for maintainer mode. (but then I never VC files it generates, either) I argue that if someone changes Makefile.am or configure.ac and that does not cause a rule to rerun the proper tools to update all dependents, then *that* is a bug. A common argument in favor of --maintainer-mode is that it helps protect users who change those files without realizing they would then have to have reasonably modern build-from-clone tools installed. These days, people are far more likely to know that those tools may be required than they were when --maintainer-mode was added.