configure{.in,} question

configure{.in,} question

[Lars Magne Ingebrigtsen]

I was going to remove the (BROKEN) from the gnutls conf option in
configure.in, but when I then said "autoconf" (aren't we supposed to
after all configure.in changes?), I got a somewhat big change in the
configure file, with lots gcc changes and stuff:

=== modified file 'configure'
*** configure	2010-10-12 21:03:09 +0000
--- configure	2010-10-24 17:26:15 +0000
***************
*** 5506,5524 ****
  fi
  
  
! if test x$GCC = xyes && test "x$GCC_LINK_TEST_OPTIONS" != x
! then
!   ac_link="$ac_link $GCC_LINK_TEST_OPTIONS"
! fi
! 
! if test x$GCC = x && test "x$NON_GCC_LINK_TEST_OPTIONS" != x
! then
!   ac_link="$ac_link $NON_GCC_LINK_TEST_OPTIONS"
  fi

(bla bla)

Is this just somebody else who forgot to autoconf after previous
changes, or is my local autoconf doing odd things?  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: configure{.in,} question

[Glenn Morris]

Lars Magne Ingebrigtsen wrote:

> I was going to remove the (BROKEN) from the gnutls conf option in
> configure.in, but when I then said "autoconf" (aren't we supposed to
> after all configure.in changes?), I got a somewhat big change in the
> configure file, with lots gcc changes and stuff:

Big changes are expected if you use a different version of autoconf to
the previous guy. I try to use the same version always to avoid this.

> ! if test x$GCC = xyes && test "x$GCC_LINK_TEST_OPTIONS" != x
> ! then
> !   ac_link="$ac_link $GCC_LINK_TEST_OPTIONS"
> ! fi
> ! 
> ! if test x$GCC = x && test "x$NON_GCC_LINK_TEST_OPTIONS" != x
> ! then
> !   ac_link="$ac_link $NON_GCC_LINK_TEST_OPTIONS"
>   fi

I did not bother regenerating configure for that change, since it
purely cosmetic.

Re: configure{.in,} question

[Lars Magne Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> Big changes are expected if you use a different version of autoconf to
> the previous guy. I try to use the same version always to avoid this.

Hm.  This line didn't change when I ran autoconf:

# Generated by GNU Autoconf 2.65 for emacs 24.0.50.

So I guess it's the same thing.

>> ! if test x$GCC = xyes && test "x$GCC_LINK_TEST_OPTIONS" != x
>> ! then
>> !   ac_link="$ac_link $GCC_LINK_TEST_OPTIONS"
>> ! fi
>> ! 
>> ! if test x$GCC = x && test "x$NON_GCC_LINK_TEST_OPTIONS" != x
>> ! then
>> !   ac_link="$ac_link $NON_GCC_LINK_TEST_OPTIONS"
>>   fi
>
> I did not bother regenerating configure for that change, since it
> purely cosmetic.

So...  I should just commit this, even though this has nothing to do
with the change I was making in configure.in?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: configure{.in,} question

[Glenn Morris]

Lars Magne Ingebrigtsen wrote:

> Hm.  This line didn't change when I ran autoconf:
>
> # Generated by GNU Autoconf 2.65 for emacs 24.0.50.

I don't know why you would get a "somewhat big" diff then, but don't
worry about it. Maybe nobody regenerated configure for a while. Or
sometimes eg Debian seems to have local patches to autoconf so that
their version behaves a bit differently to others with the same
version number.

> So...  I should just commit this, even though this has nothing to do
> with the change I was making in configure.in?

Sure. Just describe it as "regenerate configure".


I have wondered whether configure even needs to be in the repository.
Here is something I wrote once but never bothered to send till now:


configure should be included in release tarfiles, but should it be
kept in the repository, or should just configure.in be there?

Problems causes by keeping configure in the repository:

1) Need for developers to regenerate it and check it in.

2) Often leads to large, meaningless diffs. For example, the merge of
the imagemagick branch had a diff of about 2500 lines. 1500 lines of
this were configure, and so totally meaningless.

Different developers using different versions of autoconf to generate
configure often leads to large diffs that bury the real change to
configure.in amongst noise. It's lead to the situation where AC_PREREQ
is artificially high, simply to try to stop this. I don't think this
is a good solution.

3) More problems with merges between branches, I imagine.

4) People in the habit of running autoconf are likely to end up with
conflicts when configure is updated.

5) ... ?


Advantages to keeping configure in the repository:

1) People don't need autoconf installed. I think this is a small
advantage, since autoconf is commonly present and easy to install.

2) The configure script gets more thorough testing (if is generated by
developers with a fixed version of autoconf and people don't
regenerate it).

3) ... ?

Re: configure{.in,} question

[Stephen J. Turnbull]

Glenn Morris writes:
 > Lars Magne Ingebrigtsen wrote:
 > 
 > > Hm.  This line didn't change when I ran autoconf:
 > >
 > > # Generated by GNU Autoconf 2.65 for emacs 24.0.50.
 > 
 > I don't know why you would get a "somewhat big" diff then,

Because all the line numbers in the following error messages change,
most likely.

Re: configure{.in,} question

[Andreas Schwab]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Glenn Morris writes:
>  > Lars Magne Ingebrigtsen wrote:
>  > 
>  > > Hm.  This line didn't change when I ran autoconf:
>  > >
>  > > # Generated by GNU Autoconf 2.65 for emacs 24.0.50.
>  > 
>  > I don't know why you would get a "somewhat big" diff then,
>
> Because all the line numbers in the following error messages change,
> most likely.

Which line numbers?

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: configure{.in,} question

[Julien Danjou]

On Sun, Oct 24 2010, Glenn Morris wrote:

> I have wondered whether configure even needs to be in the repository.

Me too. Almost all project I know using which are using autoconf do not
store the configure file for obvious reasons you cited.
I really think it's bad practice to store that in the repository.

It's like you were storing .o files. :)

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

Re: configure{.in,} question

[Andreas Schwab]

Julien Danjou <julien@danjou.info> writes:

> It's like you were storing .o files. :)

Except that it is completely unlike.

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: configure{.in,} question

[Eli Zaretskii]

> From: Julien Danjou <julien@danjou.info>
> Date: Mon, 25 Oct 2010 10:47:39 +0200
> Cc: emacs-devel@gnu.org
> 
> On Sun, Oct 24 2010, Glenn Morris wrote:
> 
> > I have wondered whether configure even needs to be in the repository.
> 
> Me too. Almost all project I know using which are using autoconf do not
> store the configure file for obvious reasons you cited.
> I really think it's bad practice to store that in the repository.

But doing so makes sure everybody can run the configure script, even
if the version of Autoconf installed on the user's machine has some
bug that affects Emacs.

> It's like you were storing .o files. :)

Not like that at all.  Not every generated file should be omitted.  We
have other generated files in the repository, take a look at
admin/charsets and admin/unidata.  There's nothing wrong with that,
really.

Re: configure{.in,} question

[Stephen J. Turnbull]

Andreas Schwab writes:

 > Which line numbers?

The self-referential ones.

Re: configure{.in,} question

[Andreas Schwab]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Andreas Schwab writes:
>
>  > Which line numbers?
>
> The self-referential ones.

Can you expand?

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: configure{.in,} question

[Stephen J. Turnbull]

Andreas Schwab writes:
 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
 > 
 > > Andreas Schwab writes:
 > >
 > >  > Which line numbers?
 > >
 > > The self-referential ones.
 > 
 > Can you expand?

No, I let m4 do that for me.

More to the point.  It used to be the case that autoconf (say 2.13)
would embed line number information like this:

#line 1775 "configure"

and those numbers would change if you added or removed code in
configure.in.  Evidently I haven't done a diff on configure in over 5
years, but the memory of that pain is still fresh. :-)

Re: configure{.in,} question

[Stefan Monnier]

> Not like that at all.  Not every generated file should be omitted.  We
> have other generated files in the repository, take a look at
> admin/charsets and admin/unidata.  There's nothing wrong with that,
> really.

Actually, storing generated files is always a source of annoyances.
For files that change very rarely, like the unicode char data, this is
not too problematic, but I often end up with problems because of
configure and src/config.in.  I worked around most of those problems in
my local branch by "bzr mv"ing those files to a "junk" directory.

Of course, there are yet other generated files which change somewhat
often but that we need for bootstrapping reasons.

This said, I'd be happy to try and move all those generated files to
some auxiliary place, so as to better balance the conflict between "we
want to have them to make installation easier and bootstrap possible"
and "we don't want to store generated files, to avoid conflicts".

We already do that with lisp/loaddefs.el (whose bootstrap version is in
lisp/ldefs-boot.el), but maybe a more generic approach would be
desirable.
Even better would be if Bzr provided support for such things.


        Stefan

Re: configure{.in,} question

[Glenn Morris]

Eli Zaretskii wrote:

> But doing so makes sure everybody can run the configure script, even
> if the version of Autoconf installed on the user's machine has some
> bug that affects Emacs.

If we are aware of such problems, that is a legitimate reason to set
AC_PREREQ in configure.in to avoid those versions of autoconf.
We have done this in the past, although AFAIK the current prereq is
artificially high simply to stop version churn.

Re: configure{.in,} question

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Julien Danjou <julien@danjou.info>,  emacs-devel@gnu.org
> Date: Mon, 25 Oct 2010 12:06:43 -0400
> 
> Actually, storing generated files is always a source of annoyances.
> For files that change very rarely, like the unicode char data, this is
> not too problematic, but I often end up with problems because of
> configure and src/config.in.

Including with bzr?  What problems are those?  Bzr is much better than
CVS in handling conflicts, so much so that I sometimes suspect it
silently did the wrong thing (but it doesn't).

> Even better would be if Bzr provided support for such things.

If you can define the requirements, it might be worth to ask for such
a feature on the Bazaar list.  If you get lucky, you could have a POC
plugin in a matter of days.

Re: configure{.in,} question

[Glenn Morris]

Eli Zaretskii wrote:

>> I often end up with problems because of configure and
>> src/config.in.
>
> Including with bzr?  What problems are those?

If you run autoconf locally (which I think is good practice), and you
did not use the same version as the person who last committed
configure, you WILL get a conflict when you update. Eg

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6428
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6536

I update and build my local copy of Emacs with a script, and I run
`bzr revert --no-backup configure src/config.in'
before `bzr pull/up' (and later `autoconf') to avoid this problem.

> a feature on the Bazaar list.  If you get lucky, you could have a POC
> plugin in a matter of days.

But we cannot make everyone who checks out Emacs from bzr use said
plugin.

Re: configure{.in,} question

[Ted Zlatanov]

On Sun, 24 Oct 2010 19:31:10 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> I was going to remove the (BROKEN) from the gnutls conf option in
LMI> configure.in

You think it's ready for normal use?  I'd mark it "experimental."

LMI> but when I then said "autoconf" (aren't we supposed to after all
LMI> configure.in changes?)

IIRC you have to `autoreconf' instead.

Ted

Re: configure{.in,} question

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> You think it's ready for normal use?  I'd mark it "experimental."

I've used it exclusively for all the TLS connections in Emacs for weeks,
and it works for me...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: configure{.in,} question

[Ted Zlatanov]

On Mon, 25 Oct 2010 21:13:11 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> You think it's ready for normal use?  I'd mark it "experimental."

LMI> I've used it exclusively for all the TLS connections in Emacs for weeks,
LMI> and it works for me...

Wonderful, that makes 1.5 of us (I only use it half the time due to work
policies).

Ted

Re: configure{.in,} question

[Stefan Monnier]

>> Even better would be if Bzr provided support for such things.
> If you can define the requirements, it might be worth to ask for such
> a feature on the Bazaar list.  If you get lucky, you could have a POC
> plugin in a matter of days.

IIUC these kinds of problems may/will be helped by things like
"bzr-externals".  In any case, as long as it's not in Bzr proper, I'd
rather not make use of it for Emacs's repository.


        Stefan

Re: configure{.in,} question

[Stefan Monnier]

>>> I often end up with problems because of configure and
>>> src/config.in.
>> Including with bzr?  What problems are those?
> If you run autoconf locally (which I think is good practice), and you
> did not use the same version as the person who last committed
> configure, you WILL get a conflict when you update. Eg

Indeed.

>> a feature on the Bazaar list.  If you get lucky, you could have a POC
>> plugin in a matter of days.
> But we cannot make everyone who checks out Emacs from bzr use said
> plugin.

Actually, maybe for those files, we could use a merge-helper that just
says "use the most recent file".  Of course, since merge helpers are
plugins, that still depends on whether such a merge helper is or will
be included in Bzr proper.


        Stefan

Re: configure{.in,} question

[Lars Magne Ingebrigtsen]

Speaking of which, Andreas has just checked in configure made with
autoconf 2.68, so now there's a 4K line diff between anybody using 2.65
and what's in bzr.

If we're still going to have the configure file in bzr, would it be
possible to have the configure file be autogenerated on Savannah (or
somewhere), perhaps as a trigger after checking in configure.in?  That
way we won't get 4K line flapping between different autoconf versions,
at least.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen