autogen.sh question

autogen.sh question

[Marcin Antczak]

Hi!


Could someone explain to me why there is no 'usual' ./autogen.sh file in
emacs cvs?

And why there is ./configure in cvs instead of just ./configure.in?

I want to apply a patch to ./configure (debian-rpath workaround) and I
wonder if should I apply this patch to ./configure or to ./configure.in
and regenerate ./configure with autogen after applying patch
to ./configure.in.


Marcin

Re: autogen.sh question

[Thien-Thi Nguyen]

Marcin Antczak <marcin.antczak@orange.pl> writes:

> Could someone explain to me why there is no 'usual' ./autogen.sh
> file in emacs cvs?

emacs is unusual because its early development preceded that of
the GNU auto* tools (and in some cases even influenced their
design, iirc).  at some point emacs began to use autoconf but not
automake, so if an autogen.sh were ever to be introduced its sole
command would be to run autoconf.  probably not worth the trouble.
 
> And why there is ./configure in cvs instead of just
> ./configure.in?

so that people checking out a source tree from cvs can use the
./configure script immediately, w/o having to install autoconf.

> I want to apply a patch to ./configure (debian-rpath workaround)
> and I wonder if should I apply this patch to ./configure or to
> ./configure.in and regenerate ./configure with autogen after
> applying patch to ./configure.in.

configure.in is the source, so the patch should be applied there.

the top-level ChangeLog gives a hint about the practice: modify
configure.in, regenerate configure, and check in both files.  when
i have done this in the past, i checked in configure.in first,
waited a few seconds (maybe half a minute), and then configure.
in the ChangeLog, however, i recorded both edits in one entry.

thi

Re: autogen.sh question

[Paul Pogonyshev]

Thien-Thi Nguyen wrote:
> > And why there is ./configure in cvs instead of just
> > ./configure.in?
>
> so that people checking out a source tree from cvs can use the
> ./configure script immediately, w/o having to install autoconf.

From my personal experience I have concluded that the odds to
successfully run `autogen.sh' for a person not involved in project
is very low and tends to zero as project size increases.  I think
it is important that `configure' is in CVS _especially_ for a
project with such a slow release cycle as Emacs has.  I always
use CVS Emacs and I'm very happy with not having to run some
specific version of Autoconf.

Paul

Re: autogen.sh question

[Daniel Brockman]

Thien-Thi Nguyen <ttn@gnu.org> writes:

> modify configure.in, regenerate configure, and check in
> both files.  when i have done this in the past, i checked
> in configure.in first, waited a few seconds (maybe half a
> minute), and then configure.

Why did you wait before checking in `configure'?

-- 
Daniel Brockman <daniel@brockman.se>

Re: autogen.sh question

[Thien-Thi Nguyen]

Daniel Brockman <daniel@brockman.se> writes:

> Why did you wait before checking in `configure'?

superstition from old experience w/ (flaky) cvs over nfs problems
combined w/ automake-influenced (thus, irrelevant in this context)
methodology -- all this from other projects, not emacs.  the idea
is to ensure timestamps of freshly checked out files to be in order
of configure.in older than configure.

(my confusion runs deep, but the practice is (apparently) harmless.)

thi

Re: autogen.sh question

[Eli Zaretskii]

> From: Thien-Thi Nguyen <ttn@gnu.org>
> Date: 25 Sep 2005 17:36:45 -0400
> Cc: emacs-devel@gnu.org
> 
> the top-level ChangeLog gives a hint about the practice: modify
> configure.in, regenerate configure, and check in both files.

Not only configure needs to be regenerated; src/config.in is another
file that needs to be remade (with `autoheader') whenever configure.in
changes.