Change to bzr build instructions

Change to bzr build instructions

[Glenn Morris]

The following only applies to platforms that use the configure script.

The autotools generated files such as configure are no longer present in
the repository in the trunk. Instead you should generate them yourself
using the autogen.sh script. See INSTALL.BZR for details.

Developers: there is no longer any need to commit autotools generated
files. The versions in autogen/ will hopefully be kept up-to-date by a
daily cron job running on fencepost.

I look forward to it all blowing up in 3,2,...

Re: Change to bzr build instructions

[Glenn Morris]

PS If you have been running autoconf etc locally, you will probably have
conflicts that need resolving the next time you update from bzr, due to
the removal of files that you have locally modified.

Re: Change to bzr build instructions

[Jim Meyering]

Glenn Morris wrote:
> The following only applies to platforms that use the configure script.
>
> The autotools generated files such as configure are no longer present in
> the repository in the trunk. Instead you should generate them yourself
> using the autogen.sh script. See INSTALL.BZR for details.
>
> Developers: there is no longer any need to commit autotools generated
> files. The versions in autogen/ will hopefully be kept up-to-date by a
> daily cron job running on fencepost.

Nice.  Thanks for doing that!

Re: Change to bzr build instructions

[Stefan Monnier]

> The autotools generated files such as configure are no longer present in
> the repository in the trunk. Instead you should generate them yourself
> using the autogen.sh script. See INSTALL.BZR for details.

I just tried it on a machine whose autoconf is older than 2.65 and while
I got it to work, there are some problems.  Mostly the problem is that
after running copy_autogen, it still tried to run autoheader.  I had to
"touch src/stamp-h.in".  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".

Another (minor) problem is that it's a lot more convenient to run
./autogen/copy than to cd into autogen to run ./copy and then cd back
out of it.


        Stefan

Re: Change to bzr build instructions

[Glenn Morris]

Stefan Monnier wrote:

>  Mostly the problem is that after running copy_autogen, it still tried
> to run autoheader. I had to "touch src/stamp-h.in".

I added that, basically.

> 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.

> Another (minor) problem is that it's a lot more convenient to run
> ./autogen/copy than to cd into autogen to run ./copy and then cd back
> out of it.

OK, now either works.

Re: Change to bzr build instructions

[Stefan Monnier]

>> Mostly the problem is that after running copy_autogen, it still tried
>> to run autoheader. I had to "touch src/stamp-h.in".
> I added that, basically.

Good, thanks.

>> 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.

>> Another (minor) problem is that it's a lot more convenient to run
>> ./autogen/copy than to cd into autogen to run ./copy and then cd back
>> out of it.
> OK, now either works.

Great, thanks,


        Stefan

Re: Change to bzr build instructions

[Glenn Morris]

>>> 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

(or is it actually recommending removing the option altogether, and
having it always on?)

Re: Change to bzr build instructions

[Jim Meyering]

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]

Glenn Morris <rgm@gnu.org> writes:

> The autotools generated files such as configure are no longer present in
> the repository in the trunk. Instead you should generate them yourself
> using the autogen.sh script. See INSTALL.BZR for details.

You should also remove all the other files that would be added by
running autoreconf (config.{guess,sub}, depcomp, missing, etc.).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Change to bzr build instructions

[Glenn Morris]

Andreas Schwab wrote:

> You should also remove all the other files that would be added by
> running autoreconf (config.{guess,sub}, depcomp, missing, etc.).

Awesome, I'll remove them in a few days if no-one objects; and make the
required changes to autogen.sh, autogen/, etc.

I think the list is:

compile config.guess config.sub depcomp install-sh missing

(technically could also do texinfo.tex, but I won't)

The only reason I can see to keep some or all of these files is if for
some reason Emacs has to have the very latest version (compared to what
automake 1.11 supplies).

Re: Change to bzr build instructions

[Andreas Röhler]

Am 21.03.2011 01:24, schrieb Glenn Morris:
>
> The following only applies to platforms that use the configure script.
>
> The autotools generated files such as configure are no longer present in
> the repository in the trunk. Instead you should generate them yourself
> using the autogen.sh script. See INSTALL.BZR for details.
>
> Developers: there is no longer any need to commit autotools generated
> files. The versions in autogen/ will hopefully be kept up-to-date by a
> daily cron job running on fencepost.
>
> I look forward to it all blowing up in 3,2,...
>
>

Hi,

got today:

  ./autogen.sh
Checking whether you have the necessary tools...
(Read INSTALL.BZR for more details on building Emacs)

Checking for autoconf (need at least version 2.65)...
ok
Checking for automake (need at least version 1.11)...
ok
Your system has the required tools, running autoreconf...
Can't locate Autom4te/ChannelDefs.pm in @INC (@INC contains: 
/usr/share/autoconf /usr/lib/perl5/5.10.0/i586-linux-thread-multi 
/usr/lib/perl5/5.10.0 
/usr/lib/perl5/site_perl/5.10.0/i586-linux-thread-multi 
/usr/lib/perl5/site_perl/5.10.0 
/usr/lib/perl5/vendor_perl/5.10.0/i586-linux-thread-multi 
/usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .) at 
/usr/bin/autoreconf line 42.
BEGIN failed--compilation aborted at /usr/bin/autoreconf line 42.


on Suse-11.2
Linux 2.6.31.14-0.6-default #1 SMP 2010-12-10 11:18:32 +0100 i686 i686 
i386 GNU/Linux

BTW this installation seems to have some odds, error might be here.

Thanks


Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/

Re: Change to bzr build instructions

[Harald Hanche-Olsen]

[Glenn Morris <rgm@gnu.org> (2011-03-21 00:24:50 UTC)]

> The autotools generated files such as configure are no longer present in
> the repository in the trunk. Instead you should generate them yourself
> using the autogen.sh script. See INSTALL.BZR for details.

I got the following result:

; ./autogen.sh
Checking whether you have the necessary tools...
(Read INSTALL.BZR for more details on building Emacs)

Checking for autoconf (need at least version 2.65)...
ok
Checking for automake (need at least version 1.11)...
ok
Your system has the required tools, running autoreconf...
Can't exec "libtoolize": No such file or directory at /usr/bin/autoreconf line 189.
Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf line 189.
You can now run `./configure'.

Apparently, that is a successful run despite the errors?

- Harald

Re: Change to bzr build instructions

[Glenn Morris]

Harald Hanche-Olsen wrote:

> Can't exec "libtoolize": No such file or directory at /usr/bin/autoreconf line 189.
> Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf line 189.
> You can now run `./configure'.

Sorry, I don't understand that. Emacs does not use libtool (AFAIK), and
it works fine for me on a system without it installed. Perhaps it is a
bug in whatever your version of autoreconf is? In any case, it still
exits with status 0, so I think this is just a cosmetic issue that you
can ignore.

Re: Change to bzr build instructions

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Sun, 20 Mar 2011 20:24:50 -0400
> 
> 
> The autotools generated files such as configure are no longer present in
> the repository in the trunk.

Why were these files deleted and then created anew in autogen/?  Why
not "bzr mv" them instead?  Do we really want to lose their history?

Re: Change to bzr build instructions

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Glenn Morris <rgm@gnu.org>
>> Date: Sun, 20 Mar 2011 20:24:50 -0400
>> 
>> 
>> The autotools generated files such as configure are no longer present
>> in the repository in the trunk.
>
> Why were these files deleted and then created anew in autogen/?  Why
> not "bzr mv" them instead?  Do we really want to lose their history?

One thing that makes sense about git: moving files is exactly the same
as deleting and recreating them.  History is reconstructed on the fly
when you ask for it and tracks the contents, not the file names (though
they provide starting points for he heuristics).  So you don't depend on
the programmer telling the system how content moved about.

-- 
David Kastrup

Re: Change to bzr build instructions

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Fri, 25 Mar 2011 11:04:24 +0100
> 
> > Why were these files deleted and then created anew in autogen/?  Why
> > not "bzr mv" them instead?  Do we really want to lose their history?
> 
> One thing that makes sense about git: moving files is exactly the same
> as deleting and recreating them.

Please stop the git propaganda here.  The advantages and disadvantages
of git vs bzr in this regard are well known and can be found with
Google.

Re: Change to bzr build instructions

[Leo]

On 2011-03-25 18:18 +0800, Eli Zaretskii wrote:
> Please stop the git propaganda here.  The advantages and disadvantages
> of git vs bzr in this regard are well known and can be found with
> Google.

I see no propaganda here. David merely mentions the way git handles
renames etc which is obviously better than bzr's. Why would bzr insist
people remember to use bzr mv instead of the shell command mv?

BTW, having used bzr recently I have realised how restrictive that tool
is!

Leo

Re: Change to bzr build instructions

[David Kastrup]

Leo <sdl.web@gmail.com> writes:

> On 2011-03-25 18:18 +0800, Eli Zaretskii wrote:
>> Please stop the git propaganda here.  The advantages and disadvantages
>> of git vs bzr in this regard are well known and can be found with
>> Google.
>
> I see no propaganda here.  David merely mentions the way git handles
> renames etc which is obviously better than bzr's.

Uh, git does not "handle" renames, tracking them not at all.  That's not
actually "better" (and in fact, git history, particularly annotating and
blaming is not the fastest as one consequence of this design choice).
But it leaves one less opportunity for manual mistakes.

> Why would bzr insist people remember to use bzr mv instead of the
> shell command mv?

Because it is a different approach.  Explicit information, when given,
beats guesswork.  One has to keep in mind that Linux, for which git was
designed, is a large-scale fast-turnaround software system with vast
amounts of information flow and very widely distributed responsibility
and mergeflows.  Maintaining any side information manually (like we do
with ChangeLog files) is more likely to be affected by shoddiness.  We
all know how much fun the ChangeLog files and their merges are in
distributed development.  When people try doing the same things with
slightly different workflow, it is convenient when no conflicts occur as
a result.  So git took the design choice of not even remembering things
that may or may not be shoddily maintained as "side information".

With Bzr, people need to remember to _give_ this information explicitly.
And of course this is relevant for Emacs developers using Bzr directly.

-- 
David Kastrup

Re: Change to bzr build instructions

[Eli Zaretskii]

> From: Leo <sdl.web@gmail.com>
> Date: Fri, 25 Mar 2011 19:44:19 +0800
> 
> David merely mentions the way git handles renames etc which is
> obviously better than bzr's.

It's not obviously better.

> Why would bzr insist people remember to use bzr mv instead of the
> shell command mv?

Because that way, there's no heuristics involved in inferring whether
a file was renamed or not.  With bzr, renaming while also modifying
the file's contents can be safely done in one commit instead of two.

> BTW, having used bzr recently I have realised how restrictive that tool
> is!

You need to learn how to use it and you need to "think Bazaar", not
git.

If you have constructive criticism and proposals, please post them to
bazaar@lists.canonical.com.  This forum is not the appropriate place
to discuss that, unless the issue is closely related to Emacs.

Re: Change to bzr build instructions

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Leo <sdl.web@gmail.com>
>
>> Why would bzr insist people remember to use bzr mv instead of the
>> shell command mv?
>
> Because that way, there's no heuristics involved in inferring whether
> a file was renamed or not.  With bzr, renaming while also modifying
> the file's contents can be safely done in one commit instead of two.

Safety does not come into play here.  You can, of course, do the same in
git.  If you do this frequently, it makes sense to tell git to work
harder when reconstructing history.  When you do, git can also make
sense out of material factored out from several files into a single one
and vice versa, something which can't be told bzr as far as I know.

Of course, you need to _know_ when it will be helpful to ask for more,
and it might be an easier choice for the person actually doing the
checkin.  While it is usually easier to ask an automated tool for
working harder right now than a human, as long as the respective
information is likely to be read more often than written, letting the
human do the work while he still has complete knowledge about what he is
doing is a reasonable tradeoff.

The problem is when people consider it likely that nobody will actually
need this information: in that case still writing it requires
discipline.

And Eli asked for keeping this discipline because it makes life easier
in the long run given our choice of tools.

-- 
David Kastrup

Re: Change to bzr build instructions

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Fri, 25 Mar 2011 14:52:33 +0100
> 
> And Eli asked for keeping this discipline because it makes life easier
> in the long run given our choice of tools.

Actually, my main problem is forensics: the ability to tell which
commit made a certain change.

Re: Change to bzr build instructions

[Andreas Röhler]

[ .. ] Why would bzr insist
> people remember to use bzr mv instead of the shell command mv?

[ ... ]

Does it?

When copying whole bzr-directories with shell didn't notice a loss. (?)

Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/

Re: Change to bzr build instructions

[Davis Herring]

>> [ .. ] Why would bzr insist
>> people remember to use bzr mv instead of the shell command mv?
>
> Does it?
>
> When copying whole bzr-directories with shell didn't notice a loss. (?)

This is for moves within (not of) working copies that one intends to commit.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Change to bzr build instructions

[Ted Zlatanov]

On Fri, 25 Mar 2011 19:44:19 +0800 Leo <sdl.web@gmail.com> wrote: 

L> On 2011-03-25 18:18 +0800, Eli Zaretskii wrote:
>> Please stop the git propaganda here.  The advantages and disadvantages
>> of git vs bzr in this regard are well known and can be found with
>> Google.

L> I see no propaganda here. David merely mentions the way git handles
L> renames etc which is obviously better than bzr's. Why would bzr insist
L> people remember to use bzr mv instead of the shell command mv?

David's post was completely besides the point.  Eli was asking people to
use "bzr mv" which is reasonable.  What does it matter how Git does it?

L> BTW, having used bzr recently I have realised how restrictive that tool
L> is!

Bazaar is no git[1] and Git is no bazaar.  There, it's settled.

Ted

[1] http://www.urbandictionary.com/define.php?term=git

Re: Change to bzr build instructions

[David Kastrup]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Fri, 25 Mar 2011 19:44:19 +0800 Leo <sdl.web@gmail.com> wrote: 
>
> L> On 2011-03-25 18:18 +0800, Eli Zaretskii wrote:
>>> Please stop the git propaganda here.  The advantages and disadvantages
>>> of git vs bzr in this regard are well known and can be found with
>>> Google.
>
> L> I see no propaganda here. David merely mentions the way git handles
> L> renames etc which is obviously better than bzr's. Why would bzr insist
> L> people remember to use bzr mv instead of the shell command mv?
>
> David's post was completely besides the point.  Eli was asking people to
> use "bzr mv" which is reasonable.  What does it matter how Git does it?

Because one can presumably use

    bzr git-apply

or

    bzr git-import

in order to get automated move information from a local git mirror into
Bazaar if one wants to avoid remembering to specify moves manually each
time?

-- 
David Kastrup

Re: Change to bzr build instructions

[Ted Zlatanov]

On Fri, 25 Mar 2011 16:03:52 +0100 David Kastrup <dak@gnu.org> wrote: 

>> David's post was completely besides the point.  Eli was asking people to
>> use "bzr mv" which is reasonable.  What does it matter how Git does it?

DK> Because one can presumably use

DK>     bzr git-apply

DK> or

DK>     bzr git-import

DK> in order to get automated move information from a local git mirror into
DK> Bazaar if one wants to avoid remembering to specify moves manually each
DK> time?

I was not aware of that plugin, thanks for explaining (I found more
details at https://launchpad.net/bzr-git).  So really you were saying
"if you use the bzr-git plugin you could avoid these mistakes" which is
a different message :)

Ted

Re: Change to bzr build instructions

[David Kastrup]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I was not aware of that plugin, thanks for explaining (I found more
> details at https://launchpad.net/bzr-git).  So really you were saying
> "if you use the bzr-git plugin you could avoid these mistakes" which is
> a different message :)

I was not really saying that at first.  Instead I shamelessly used the
situation after the fact for supplying hopefully useful information
after all.

-- 
David Kastrup

Re: Change to bzr build instructions

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Fri, 25 Mar 2011 16:03:52 +0100
> 
> Because one can presumably use
> 
>     bzr git-apply
> 
> or
> 
>     bzr git-import
> 
> in order to get automated move information from a local git mirror into
> Bazaar if one wants to avoid remembering to specify moves manually each
> time?

If you have bzr-git installed, you can simply say "bzr merge" or "bzr
pull".

IOW, that plugin makes git repositories first-class bzr citizens
(except that "bzr push" doesn't work yet, so you can only use the git
repo in read-only mode).  I actually use this to track several git
repositories, and my experience is very good, with a single exception:
the original "bzr branch" command is painfully slow for repositories
with many revisions, because the step that computes bzr metadata from
git takes a very long time (I filed a bug report about that).

Re: Change to bzr build instructions

[Stefan Monnier]

>> Please stop the git propaganda here.  The advantages and disadvantages
>> of git vs bzr in this regard are well known and can be found with
>> Google.
> I see no propaganda here.

That's just because you're biased, like we all are.  It's not relevant
to emacs-devel, so let's please stop this discussion right there.
Emacs is using Bazaar, so what git does is irrelevant.
As for the original post, yes, "bzr mv" would have been better.
These aren't files where history is important, but we need to remember
to do it better as a matter of course.


        Stefan

Re: Change to bzr build instructions

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I see no propaganda here.
>
> That's just because you're biased, like we all are.  It's not relevant
> to emacs-devel, so let's please stop this discussion right there.

But note that even if some people don't like anti-bzr comments,
_replying_ to them is probably more counter-productive than the comments
themselves:  such comments aren't going to stop, so there's little point
in trying to stop them, and there's no need to turn them into threads...

-Miles

-- 
((lambda (x) (list x x)) (lambda (x) (list x x)))