[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Change to bzr build instructions
From: |
Jim Meyering |
Subject: |
Re: Change to bzr build instructions |
Date: |
Tue, 22 Mar 2011 09:08:32 +0100 |
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.
Re: Change to bzr build instructions, Andreas Schwab, 2011/03/22
Re: Change to bzr build instructions, Andreas Röhler, 2011/03/22
Re: Change to bzr build instructions, Harald Hanche-Olsen, 2011/03/22
Re: Change to bzr build instructions, Eli Zaretskii, 2011/03/25