* Re: /srv/bzr/emacs/trunk r103850: update_autogen [not found] <E1Q7YEZ-0005TE-HZ@colonialone.fsf.org> @ 2011-04-07 2:18 ` Glenn Morris 2011-04-07 5:03 ` Paul Eggert 0 siblings, 1 reply; 11+ messages in thread From: Glenn Morris @ 2011-04-07 2:18 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: /srv/bzr/emacs/trunk r103850: update_autogen 2011-04-07 2:18 ` /srv/bzr/emacs/trunk r103850: update_autogen Glenn Morris @ 2011-04-07 5:03 ` Paul Eggert 2011-04-07 16:28 ` Glenn Morris 0 siblings, 1 reply; 11+ messages in thread From: Paul Eggert @ 2011-04-07 5:03 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: /srv/bzr/emacs/trunk r103850: update_autogen 2011-04-07 5:03 ` Paul Eggert @ 2011-04-07 16:28 ` Glenn Morris 2011-04-07 18:26 ` Paul Eggert 0 siblings, 1 reply; 11+ messages in thread From: Glenn Morris @ 2011-04-07 16:28 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: /srv/bzr/emacs/trunk r103850: update_autogen 2011-04-07 16:28 ` Glenn Morris @ 2011-04-07 18:26 ` Paul Eggert 2011-04-08 0:08 ` Glenn Morris 2011-04-09 1:29 ` Stefan Monnier 0 siblings, 2 replies; 11+ messages in thread From: Paul Eggert @ 2011-04-07 18:26 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: /srv/bzr/emacs/trunk r103850: update_autogen 2011-04-07 18:26 ` Paul Eggert @ 2011-04-08 0:08 ` Glenn Morris 2011-04-08 2:04 ` Paul Eggert 2011-04-09 1:29 ` Stefan Monnier 1 sibling, 1 reply; 11+ messages in thread From: Glenn Morris @ 2011-04-08 0:08 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: /srv/bzr/emacs/trunk r103850: update_autogen 2011-04-08 0:08 ` Glenn Morris @ 2011-04-08 2:04 ` Paul Eggert 2011-04-08 4:16 ` Stephen J. Turnbull 0 siblings, 1 reply; 11+ messages in thread From: Paul Eggert @ 2011-04-08 2:04 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: /srv/bzr/emacs/trunk r103850: update_autogen 2011-04-08 2:04 ` Paul Eggert @ 2011-04-08 4:16 ` Stephen J. Turnbull 2011-04-08 6:47 ` Paul Eggert 0 siblings, 1 reply; 11+ messages in thread From: Stephen J. Turnbull @ 2011-04-08 4:16 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: /srv/bzr/emacs/trunk r103850: update_autogen 2011-04-08 4:16 ` Stephen J. Turnbull @ 2011-04-08 6:47 ` Paul Eggert 2011-04-08 16:09 ` Chong Yidong 0 siblings, 1 reply; 11+ messages in thread From: Paul Eggert @ 2011-04-08 6:47 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: /srv/bzr/emacs/trunk r103850: update_autogen 2011-04-08 6:47 ` Paul Eggert @ 2011-04-08 16:09 ` Chong Yidong 0 siblings, 0 replies; 11+ messages in thread From: Chong Yidong @ 2011-04-08 16:09 UTC (permalink / raw) To: Paul Eggert; +Cc: Stephen J. Turnbull, emacs-devel 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: /srv/bzr/emacs/trunk r103850: update_autogen 2011-04-07 18:26 ` Paul Eggert 2011-04-08 0:08 ` Glenn Morris @ 2011-04-09 1:29 ` Stefan Monnier 2011-04-09 17:50 ` Paul Eggert 1 sibling, 1 reply; 11+ messages in thread From: Stefan Monnier @ 2011-04-09 1:29 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: /srv/bzr/emacs/trunk r103850: update_autogen 2011-04-09 1:29 ` Stefan Monnier @ 2011-04-09 17:50 ` Paul Eggert 0 siblings, 0 replies; 11+ messages in thread From: Paul Eggert @ 2011-04-09 17:50 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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. :-) ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2011-04-09 17:50 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <E1Q7YEZ-0005TE-HZ@colonialone.fsf.org> 2011-04-07 2:18 ` /srv/bzr/emacs/trunk r103850: update_autogen Glenn Morris 2011-04-07 5:03 ` Paul Eggert 2011-04-07 16:28 ` Glenn Morris 2011-04-07 18:26 ` Paul Eggert 2011-04-08 0:08 ` Glenn Morris 2011-04-08 2:04 ` Paul Eggert 2011-04-08 4:16 ` Stephen J. Turnbull 2011-04-08 6:47 ` Paul Eggert 2011-04-08 16:09 ` Chong Yidong 2011-04-09 1:29 ` Stefan Monnier 2011-04-09 17:50 ` Paul Eggert
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.