Re: /srv/bzr/emacs/trunk r103850: update_autogen

Re: /srv/bzr/emacs/trunk r103850: update_autogen

[Glenn Morris]

Paul Eggert wrote:

> -m4_if(m4_defn([AC_AUTOCONF_VERSION]), [2.65],,
> -[m4_warning([this file was generated for autoconf 2.65.
> +m4_if(m4_defn([AC_AUTOCONF_VERSION]), [2.68],,
> +[m4_warning([this file was generated for autoconf 2.68.


Why did you regenerate these with 2.68 (or indeed at all)?
Since fencepost has 2.65, they will be reverted the next time my cron
job runs.

Re: /srv/bzr/emacs/trunk r103850: update_autogen

[Paul Eggert]

On 04/06/2011 07:18 PM, Glenn Morris wrote:

> Why did you regenerate these with 2.68 (or indeed at all)?
> Since fencepost has 2.65, they will be reverted the next time my cron
> job runs.

Tim Van Holder privately complained to me
at Wed, 06 Apr 2011 10:28:12 +0200
that the bzr tip didn't build without it.

Would it be a lot of hassle to have the
fencepost cron job use Autoconf 2.68?
It generates 'configure' scripts that are
slightly faster and more portable.
It's not a huge deal, of course.

Re: /srv/bzr/emacs/trunk r103850: update_autogen

[Glenn Morris]

Paul Eggert wrote:

> On 04/06/2011 07:18 PM, Glenn Morris wrote:
>
>> Why did you regenerate these with 2.68 (or indeed at all)?
>> Since fencepost has 2.65, they will be reverted the next time my cron
>> job runs.
>
> Tim Van Holder privately complained to me
> at Wed, 06 Apr 2011 10:28:12 +0200
> that the bzr tip didn't build without it.

I build Emacs just fine with autoconf 2.65, so I'd like to see a bug
report as to what the problem is supposed to be. If suddenly 2.68 is
needed, we should either increase AC_PREREQ, or figure out what recent
change requires 2.68 and remove it.

> Would it be a lot of hassle to have the fencepost cron job use
> Autoconf 2.68?

No, but I don't see why it should bother if configure.in does not
require such a version.

Re: /srv/bzr/emacs/trunk r103850: update_autogen

[Paul Eggert]

On 04/07/2011 09:28 AM, Glenn Morris wrote:

>> Tim Van Holder privately complained to me
>> at Wed, 06 Apr 2011 10:28:12 +0200
>> that the bzr tip didn't build without it.
> 
> I build Emacs just fine with autoconf 2.65, so I'd like to see a bug
> report as to what the problem is supposed to be.

His problem was independent of autoconf versions; it had to do
with the new config.in and configure being needed in order to generate
the proper symbols that the new src/*.c files were using.  He didn't
have a proper autoconf on his platform, and so was relying on the
fallback copies of config.in and configure that are checked in somewhere
else.

>> Would it be a lot of hassle to have the fencepost cron job use
>> Autoconf 2.68?
> 
> No, but I don't see why it should bother if configure.in does not
> require such a version.

Well, for one thing, we'll avoid unnecessary churning due only
to Autoconf version skew.  :-)  If we're going to use some
Autoconf version for the cron job, we might as well use the
latest stable version, since it generates a bit better output.

Again, it's no big deal, as maintainers should be expected to
work around any of these issues.  I do hope, though, that the
latest Autoconf is used whenever we make a tarball intended for
non-maintainers.

Re: /srv/bzr/emacs/trunk r103850: update_autogen

[Glenn Morris]

Paul Eggert wrote:

> His problem was independent of autoconf versions; it had to do
> with the new config.in and configure being needed in order to generate
> the proper symbols that the new src/*.c files were using.

I don't see any changes between r103843, when cron commited regenerated
configure etc, and r103849, that would necessitate regenerating again.
That's why I assumed you specifically wanted 2.68.

But of course in principle there can be a delay of up to 24hrs in
regenerating. I can increase the cron frequency if people both cannot
wait that long and cannot install autoconf.

> Well, for one thing, we'll avoid unnecessary churning due only
> to Autoconf version skew.  :-) 

Not necessarily, since there is no guarantee that anyone who does a
manual update will use 2.68.

Re: /srv/bzr/emacs/trunk r103850: update_autogen

[Paul Eggert]

On 04/07/2011 05:08 PM, Glenn Morris wrote:
> I don't see any changes between r103843, when cron commited regenerated
> configure etc, and r103849

Possibly the cron job fixed the problem before I got around to it?

> there is no guarantee that anyone who does a
> manual update will use 2.68.

That's true, just as there's no guarantee that they'll use
Autoconf 2.65.

But why not use the latest Autoconf version in the cron job?
I don't see the downside.

Re: /srv/bzr/emacs/trunk r103850: update_autogen

[Stephen J. Turnbull]

Paul Eggert writes:

 > But why not use the latest Autoconf version in the cron job?
 > I don't see the downside.

People will depend on the cron job, and neologisms will creep in.
That's not a downside for you, but it's a bad thing because it
punishes the occasional developer, especially in the case of autotools
which are famous for breaking backward compatibility and far too often
require fragile workarounds depending on what should be internal
implementation details.  When the bright shiny things crowd starts
complaining that it's way too hard to do what they want to do without
the neologisms, that's when to think about bumping requirements of
versions of tools you're not directly involved in developing, and
using the new base requirement for automated production.

Re: /srv/bzr/emacs/trunk r103850: update_autogen

[Paul Eggert]

On 04/07/2011 09:16 PM, Stephen J. Turnbull wrote:
> Paul Eggert writes:
> 
>  > But why not use the latest Autoconf version in the cron job?
>  > I don't see the downside.
> 
> People will depend on the cron job, and neologisms will creep in.

(shrug)  I don't see that as something requiring us to use old tools
when we generate software.  If someone inadvertently puts in
something that requires Autoconf 2.68, then we can yank it out,
just as we yank out code requiring GNU Make 3.82 or GCC 4.6.0 or whatever.

Again, for maintainers it's no big deal.  I just hope that when we
cut tarballs for non-maintainers that we use the better tools.

Re: /srv/bzr/emacs/trunk r103850: update_autogen

[Chong Yidong]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 04/07/2011 09:16 PM, Stephen J. Turnbull wrote:
>> Paul Eggert writes:
>>
>>  > But why not use the latest Autoconf version in the cron job?
>>  > I don't see the downside.
>>
>> People will depend on the cron job, and neologisms will creep in.
>
> (shrug)  I don't see that as something requiring us to use old tools
> when we generate software.  If someone inadvertently puts in
> something that requires Autoconf 2.68, then we can yank it out,
> just as we yank out code requiring GNU Make 3.82 or GCC 4.6.0 or whatever.
>
> Again, for maintainers it's no big deal.  I just hope that when we
> cut tarballs for non-maintainers that we use the better tools.

IIRC, in the past we've encountered Autoconf bugs going both ways
(i.e. in versions that are new and versions that are old).  When we
begin pretesting Emacs 24, we will want to pick one Autoconf version and
stick to it, unless/until a specific problem is found with that version.

But at the moment the choice of Autoconf version probably doesn't
matter.

Re: /srv/bzr/emacs/trunk r103850: update_autogen

[Stefan Monnier]

> Well, for one thing, we'll avoid unnecessary churning due only
> to Autoconf version skew.  :-)

People should *never* commit the autogen files by hand (except for
ldefs-boot.el where the "auto-update" tends to not know when things are
new, tho I think Glenn found a solution to that one as well).


        Stefan

Re: /srv/bzr/emacs/trunk r103850: update_autogen

[Paul Eggert]

On 04/08/2011 06:29 PM, Stefan Monnier wrote:
>> Well, for one thing, we'll avoid unnecessary churning due only
>> > to Autoconf version skew.  :-)
> People should *never* commit the autogen files by hand (except for
> ldefs-boot.el

Sorry, that was news to me.  I suggest noting this in INSTALL.BZR,
with an explanation of why it's OK that the trunk is temporarily
unbuildable to people lacking autoconf.  (Then I can point those
people to INSTALL.BZR when they send me email. :-)