config.in

config.in

[Eli Zaretskii]

Since config.in is now a derived file, we should checkin it into CVS
every time the configury changes (like it did now).  Otherwise, you
get annoyed by "cvs up".

Re: config.in

[Miles Bader]

Eli Zaretskii <eliz@fencepost.gnu.org> writes:
> Since config.in is now a derived file, we should checkin it into CVS
> every time the configury changes (like it did now).  Otherwise, you
> get annoyed by "cvs up".

Of course, we _should_ do the right thing and remove it from CVS (along
with `configure' for that matter)....

-Miles

-- 
`Life is a boundless sea of bitterness'

Re: config.in

[Colin Walters]

On Tue, 2002-04-16 at 14:45, Miles Bader wrote:
> Eli Zaretskii <eliz@fencepost.gnu.org> writes:
> > Since config.in is now a derived file, we should checkin it into CVS
> > every time the configury changes (like it did now).  Otherwise, you
> > get annoyed by "cvs up".
> 
> Of course, we _should_ do the right thing and remove it from CVS (along
> with `configure' for that matter)....

Agreed.  I don't see why we couldn't use an "autogen.sh" script like a
number of other free software projects do.  If there aren't any
objections to this idea, I'll be happy to do it.

Re: config.in

[Eli Zaretskii]

> From: Colin Walters <walters@verbum.org>
> Date: 16 Apr 2002 15:40:15 -0400
> 
> > Of course, we _should_ do the right thing and remove it from CVS (along
> > with `configure' for that matter)....
> 
> Agreed.  I don't see why we couldn't use an "autogen.sh" script like a
> number of other free software projects do.

Some do, others don't.  As a matter of fact, Emacs is the first
project I'm involved with (out of half a dozen others) where it's
suggested to do this.

> If there aren't any objections to this idea, I'll be happy to do it.

I object that we require users to install Autoconf and Automake just
to build Emacs.  Those are tools for developers, not for users.  To
say nothing of non-Posix systems where this will add yet another level
of gratuitous problems.  IMHO it doesn't make sense to go through all
that just to save us the ``cost'' of a 25KB file.

Re: config.in

[Alfred M. Szmidt]

* Eli Zaretskii writes:
> I object that we require users to install Autoconf and Automake just
> to build Emacs.  Those are tools for developers, not for users.  To
> say nothing of non-Posix systems where this will add yet another
> level of gratuitous problems.  IMHO it doesn't make sense to go
> through all that just to save us the ``cost'' of a 25KB file.

Should users use the CVS version of Emacs? Any released version should,
of course, include the generated configure script.

-- 
Alfred M. Szmidt

Re: config.in

[Eli Zaretskii]

> From: ams@kemisten.nu (Alfred M. Szmidt)
> Date: 16 Apr 2002 23:21:24 +0200
> 
> Should users use the CVS version of Emacs?

We have anon CVS so they could.  Quite a few do.

Re: config.in

[Colin Walters]

[ No need to CC me ]

On Wed, 2002-04-17 at 00:44, Eli Zaretskii wrote:
> > From: ams@kemisten.nu (Alfred M. Szmidt)
> > Date: 16 Apr 2002 23:21:24 +0200
> > 
> > Should users use the CVS version of Emacs?
> 
> We have anon CVS so they could.  Quite a few do.

As Miles said, those users are not the normal user; the CVS tree should
be intended for developers.  If we have a large number of "normal users"
using the CVS tree as their daily working environment, then this seems
to me to suggest that there is something wrong with our release process.

Incidentally, I'm working on tracking down authorship of the autogen.sh
included in the GNOME CVS repository; it wouldn't be hard to write our
own, but it would be good to reuse the already existing code.

Re: config.in

[Miles Bader]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:
> > Should users use the CVS version of Emacs?
> 
> We have anon CVS so they could.  Quite a few do.

But those that do quite definitely fall into the class of `unusually
clueful users', even if they don't write any code.  Such people are
quite competent to install the auto* tools; it's not rocket science.

In any case, the _purpose_ of the CVS repository is for development;
it's nice that `clueful' users can also use it to get the latest
sources, but that's a secondary purposes.  The proper thing to do is to
optimize the situation fo _developers_, even if it means a slight extra
inconvenience for this special class of users.

In any case (as I noted before) due to the the timestamp problem, `mere
users' that use CVS are going to end up needing the auto* tools anyway,
even if they never modify a single file, _even if_ the auto-generated
files are in CVS.

-Miles
-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

Re: config.in

[Andreas Schwab]

Miles Bader <miles@lsi.nec.co.jp> writes:

|> In any case (as I noted before) due to the the timestamp problem, `mere
|> users' that use CVS are going to end up needing the auto* tools anyway,
|> even if they never modify a single file, _even if_ the auto-generated
|> files are in CVS.

Another way to solve that is to introduce a maintainer mode as in
automake.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: config.in

[Karl Eichwalder]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> I object that we require users to install Autoconf and Automake just
> to build Emacs.

Installation of autoreconf (and all that) is already required if you
don't want to adjust all timestamps by hand to get dependencies
right...  At least, autoreconf got call as I up'ed emacs yesterday.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: config.in

[Eli Zaretskii]

> From: Karl Eichwalder <ke@gnu.franken.de>
> Date: Wed, 17 Apr 2002 02:00:50 +0200
> 
> Installation of autoreconf (and all that) is already required if you
> don't want to adjust all timestamps by hand to get dependencies
> right...  At least, autoreconf got call as I up'ed emacs yesterday.

You mean autoheader, not autoreconf, right?  I believe it gets invoked
because your config.in was the old version.  At least for me, it was
only invoked once, the first time I typed "make" after resyncing with
CVS after changes by Andreas that introduced config.in autogeneration.
The subsequent builds didn't run autoheader.

Am I missing something?

Re: config.in

[Andreas Schwab]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

|> > From: Karl Eichwalder <ke@gnu.franken.de>
|> > Date: Wed, 17 Apr 2002 02:00:50 +0200
|> > 
|> > Installation of autoreconf (and all that) is already required if you
|> > don't want to adjust all timestamps by hand to get dependencies
|> > right...  At least, autoreconf got call as I up'ed emacs yesterday.
|> 
|> You mean autoheader, not autoreconf, right?  I believe it gets invoked
|> because your config.in was the old version.

It's probably because the stamp file src/stamp-h.in was older, since that
is used to trigger autoheader (which does not touch config.in if it
didn't change, so the purpose of the stamp file is to avoid rerunning
autoheader all the time).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: config.in

[Miles Bader]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:
> I object that we require users to install Autoconf and Automake just
> to build Emacs.  Those are tools for developers, not for users.

This is not what's being suggested.  Anyone who checks emacs out of
CVS is basically not a normal user, and it's perfectly reasonable to
expect them to have normal GNU tools.

Note that even if these generated files are included, they may _still_
need the auto* programs, because CVS makes no attempt to preserve
timestamps, and the Makefile will attempt to regenerate the files
anyway (though the checked-out contents are actually `up to date').

> IMHO it doesn't make sense to go through all that just to save us the
> ``cost'' of a 25KB file.

The `cost' is not 25KB, it's all the annoyance of constantly having to
fight with CVS getting confused because a file got regenerated locally
which then doesn't match the CVS version.  In my case, this also ends
up making CVS updates take much longer because CVS ends up resending
all the `changed' files back to the server over my slooow connection.
This is all stupid, and it's not how things are supposed to work.

If people on MSDOS or whatever have a harder time to regenerate these
files, then we can find some other solution, but the default should be
what's good for GNU systems, which are by far the majority among
developers.

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: config.in

[Eli Zaretskii]

> From: Miles Bader <miles@lsi.nec.co.jp>
> Date: 17 Apr 2002 10:08:13 +0900
> 
> Anyone who checks emacs out of
> CVS is basically not a normal user, and it's perfectly reasonable to
> expect them to have normal GNU tools.

IMHO, those requirements should be kept at the minimum, and that this
should be a factor in our decisions, not something rejected off hand.

> Note that even if these generated files are included, they may _still_
> need the auto* programs, because CVS makes no attempt to preserve
> timestamps, and the Makefile will attempt to regenerate the files
> anyway (though the checked-out contents are actually `up to date').

This can be handled with a simple call to `touch', if it turns out to
be a real problem.

> > IMHO it doesn't make sense to go through all that just to save us the
> > ``cost'' of a 25KB file.
> 
> The `cost' is not 25KB, it's all the annoyance of constantly having to
> fight with CVS getting confused because a file got regenerated locally
> which then doesn't match the CVS version.  In my case, this also ends
> up making CVS updates take much longer because CVS ends up resending
> all the `changed' files back to the server over my slooow connection.

I was talking about config.in alone, not about the other generated
files.  I don't have anything against removing other generated files
we've discussed here, since they all are made during the build by
running Emacs commands.

I also doubt that the long update time you see will be significantly
affected by excluding config.in.  It's loaddefs.el that makes the
difference.

Yes, the CVS behavior whereby files are sent upstream if they are
suspected to be different is a bug (I'm being hit by that twice a
year, when the DST setting changes, because the Windows client
doesn't DTRT wrt time stamps).  But I've given up long ago on trying
to convince CVS maintainers that some of their ``features'' are
actually bad bugs, because I kept being told that I didn't understand
``the CVS spirit''.

> the default should be
> what's good for GNU systems, which are by far the majority among
> developers.

I _was_ talking about GNU systems; I build Emacs on fencepost
regularly.  I don't like to depend on the versions of the different
auto-* tools installed by sysadmins--it could just happen that they
fall out of sync, for example.  I also build both trunk and branch,
which use different Autoconf versions, so it's very easy to forget to
run an older version of Autoconf manually before running configure.
Now I will have to remember to run 2 commands by hand.  I don't want
that complication to ruin a release tarball some day.

As another data point, the GDB development keeps all regenerated
files in the CVS, including configure and even the Info files.

Re: config.in

[Miles Bader]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:
> > Anyone who checks emacs out of CVS is basically not a normal user,
> > and it's perfectly reasonable to expect them to have normal GNU
> > tools.
> 
> IMHO, those requirements should be kept at the minimum, and that this
> should be a factor in our decisions, not something rejected off hand.

I agree -- but only a factor, and a secondary one.

> > Note that even if these generated files are included, they may _still_
> > need the auto* programs, because CVS makes no attempt to preserve
> > timestamps, and the Makefile will attempt to regenerate the files
> > anyway (though the checked-out contents are actually `up to date').
> 
> This can be handled with a simple call to `touch', if it turns out to
> be a real problem.

That is an annoying and error-prone method of dealing with the problem
(and yes, it's a problem, that's why this issue keeps coming up); more
often than not, by the time you realize something's amiss, it's too
late, and CVS has screwed up the file by inserting conflict markers.

Morever, such a solution is _certainly_ not something that you'd
recommend to clueless users; it's easier to tell them to install
autoconf!

> I was talking about config.in alone, not about the other generated
> files.  I don't have anything against removing other generated files
> we've discussed here, since they all are made during the build by
> running Emacs Commands.

The _main_ problem is `configure', which is generated by autoconf.

However, if we remove configure from CVS, then we should be consistent
and remove the other autoconf generated files too, since they don't
require any additional tools.

> As another data point, the GDB development keeps all regenerated
> files in the CVS, including configure and even the Info files.

That is their decision (though I wouldn't be surprised if exactly this
same flame war pops up periodically on their mailing lists).  The
tradeoffs are not necessarily the same in every situation.

-Miles
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: config.in

[Eli Zaretskii]

> From: Miles Bader <miles@lsi.nec.co.jp>
> Date: 17 Apr 2002 14:54:35 +0900
> 
> > > Note that even if these generated files are included, they may _still_
> > > need the auto* programs, because CVS makes no attempt to preserve
> > > timestamps, and the Makefile will attempt to regenerate the files
> > > anyway (though the checked-out contents are actually `up to date').
> > 
> > This can be handled with a simple call to `touch', if it turns out to
> > be a real problem.
> 
> That is an annoying and error-prone method of dealing with the problem
> (and yes, it's a problem, that's why this issue keeps coming up); more
> often than not, by the time you realize something's amiss, it's too
> late, and CVS has screwed up the file by inserting conflict markers.
> 
> Morever, such a solution is _certainly_ not something that you'd
> recommend to clueless users; it's easier to tell them to install
> autoconf!

You misunderstood me--or rather, I didn't explain well enough what I
meant.  I didn't mean to suggest a manual `touch'.  The idea was to
put something into the configury which will do that automatically,
assuming we can detect time stamp mismatches that are produced by CVS.

> However, if we remove configure from CVS, then we should be consistent
> and remove the other autoconf generated files too, since they don't
> require any additional tools.

Yes, I agree that we should be consistent here.

> > As another data point, the GDB development keeps all regenerated
> > files in the CVS, including configure and even the Info files.
> 
> That is their decision (though I wouldn't be surprised if exactly this
> same flame war pops up periodically on their mailing lists).

FWIW, I'm reading their lists for the last couple of years, and I
don't remember any complaints.

Re: config.in

[Andreas Schwab]

Miles Bader <miles@lsi.nec.co.jp> writes:

|> That is an annoying and error-prone method of dealing with the problem
|> (and yes, it's a problem, that's why this issue keeps coming up); more
|> often than not, by the time you realize something's amiss, it's too
|> late, and CVS has screwed up the file by inserting conflict markers.

For files like config.in the chances that conflicts happen are rather low,
unless you change configure.in in the first place.  This is quite
different from loaddefs.el, which also contains local time stamps.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: config.in

[Miles Bader]

Andreas Schwab <schwab@suse.de> writes:
> For files like config.in the chances that conflicts happen are rather low,
> unless you change configure.in in the first place.  This is quite
> different from loaddefs.el, which also contains local time stamps.

Actually the file I'm really annoyed by is `configure', which has caused
me grief in the past -- the conversation about config.in just reminded
me to complain about it.

-Miles

-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: config.in

[Richard Stallman]

    Note that even if these generated files are included, they may _still_
    need the auto* programs, because CVS makes no attempt to preserve
    timestamps, and the Makefile will attempt to regenerate the files
    anyway (though the checked-out contents are actually `up to date').

This does not seem to have been a problem in the past.  For a few
months I did not have the latest Autoconf and could not regenerate
`configure'.  This was not a real problem; I ran ./configure and I
don't think anything tried to run autoconf.

Things may be different now with src/config.in.  There now seems to be
a Make rule to update that file, so it might try to run automatically.
This is no good.

We may need to delete the dependency that would run that Make rule, so
that it only runs on explicit request (or from `dist').  Or install
some sort of touch command instead.

Re: config.in

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

|> Things may be different now with src/config.in.  There now seems to be
|> a Make rule to update that file, so it might try to run automatically.
|> This is no good.

There was always a rule for configure as well, otherwise I wouldn't have
added one for config.in.  But the difference with config.in is that it
depends on a third file, src/stamp-h.in, that functions as a timestamp
file, because autoheader does not modify its output if it wouldn't change,
thus to avoid running autoheader again and again the stamp file is needed.
I have already extended make-dist to fix the timestamps for distribution.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: config.in

[Kim F. Storm]

Andreas Schwab <schwab@suse.de> writes:

> Richard Stallman <rms@gnu.org> writes:
> 
> |> Things may be different now with src/config.in.  There now seems to be
> |> a Make rule to update that file, so it might try to run automatically.
> |> This is no good.
> 
> There was always a rule for configure as well, otherwise I wouldn't have
> added one for config.in.  But the difference with config.in is that it
> depends on a third file, src/stamp-h.in, that functions as a timestamp
> file, because autoheader does not modify its output if it wouldn't change,
> thus to avoid running autoheader again and again the stamp file is needed.
> I have already extended make-dist to fix the timestamps for distribution.

I think I got lost half way through those changes....  I don't think
I'll ever dare adding a new parameter to config.in or configure :-)

May I suggest that you write a short INTRO_CVS file (not to be
included in a dist) which explains what tools are needed to
reconfigure things (autoconf version etc.), what (config related)
files are in CVS, why they are there, and what the dependencies
between all those files are.

Of course, it should also mention "make bootstrap" :-)

And it would be nice if it briefly described the steps normally taken
to build and release a new distribution (e.g. what to put into
ChangeLog, what files to update afterwards [with version info] etc.)


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: config.in

[Andreas Schwab]

storm@cua.dk (Kim F. Storm) writes:

|> Andreas Schwab <schwab@suse.de> writes:
|> 
|> > Richard Stallman <rms@gnu.org> writes:
|> > 
|> > |> Things may be different now with src/config.in.  There now seems to be
|> > |> a Make rule to update that file, so it might try to run automatically.
|> > |> This is no good.
|> > 
|> > There was always a rule for configure as well, otherwise I wouldn't have
|> > added one for config.in.  But the difference with config.in is that it
|> > depends on a third file, src/stamp-h.in, that functions as a timestamp
|> > file, because autoheader does not modify its output if it wouldn't change,
|> > thus to avoid running autoheader again and again the stamp file is needed.
|> > I have already extended make-dist to fix the timestamps for distribution.
|> 
|> I think I got lost half way through those changes....  I don't think
|> I'll ever dare adding a new parameter to config.in or configure :-)

You will not ever need to modify config.in any more.

|> May I suggest that you write a short INTRO_CVS file (not to be
|> included in a dist) which explains what tools are needed to
|> reconfigure things (autoconf version etc.), what (config related)

Just use autoconf >= 2.51, as stated in configure.in (AC_PREREQ).

|> files are in CVS, why they are there, and what the dependencies
|> between all those files are.

In addition to autoconf you just need to run autoheader to update
src/config.in.  That's all.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: config.in

[Kim F. Storm]

Andreas Schwab <schwab@suse.de> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> |> Andreas Schwab <schwab@suse.de> writes:
> |> 
> |> > Richard Stallman <rms@gnu.org> writes:
> |> > 
> |> > |> Things may be different now with src/config.in.  There now seems to be
> |> > |> a Make rule to update that file, so it might try to run automatically.
> |> > |> This is no good.
> |> > 
> |> > There was always a rule for configure as well, otherwise I wouldn't have
> |> > added one for config.in.  But the difference with config.in is that it
> |> > depends on a third file, src/stamp-h.in, that functions as a timestamp
> |> > file, because autoheader does not modify its output if it wouldn't change,
> |> > thus to avoid running autoheader again and again the stamp file is needed.
> |> > I have already extended make-dist to fix the timestamps for distribution.
> |> 
> |> I think I got lost half way through those changes....  I don't think
> |> I'll ever dare adding a new parameter to config.in or configure :-)
> 
> You will not ever need to modify config.in any more.
> 
> |> May I suggest that you write a short INTRO_CVS file (not to be
> |> included in a dist) which explains what tools are needed to
> |> reconfigure things (autoconf version etc.), what (config related)
> 
> Just use autoconf >= 2.51, as stated in configure.in (AC_PREREQ).
> 
> |> files are in CVS, why they are there, and what the dependencies
> |> between all those files are.
> 
> In addition to autoconf you just need to run autoheader to update
> src/config.in.  That's all.
> 

Ok, I can understand that....  But it would still be nice if we
documented it (for the sake of future emacs hackers and old-timers
like myself with flaky memory) and stated our policies regarding which
auto-generated files still need to be checked into CVS (e.g. config.in
is there, *.elc is not).

The file could also state how to become a developer (who to contact to
get write access), release policies, and other policies.

And the use of "make bootstrap" of course :-)

Just start small and simple -- we can enhance it on the way ...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: config.in

[Richard Stallman]

    I have already extended make-dist to fix the timestamps for distribution.

Ordinary make has to fix the timestamps too, and touch the generated
files, when you are building from CVS.  It should not attempt
to run autoconf unless the user says `make configure' or `make config.in'.

Re: config.in

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

|>     I have already extended make-dist to fix the timestamps for distribution.
|> 
|> Ordinary make has to fix the timestamps too, and touch the generated
|> files, when you are building from CVS.  It should not attempt
|> to run autoconf unless the user says `make configure' or `make config.in'.

In neither cases the makefile caters for CVS timestamp issues at the
moment.  Doing it right would require a script like gcc_update from the
gcc repository, since make cannot know whether the timestamp difference
comes from modifying configure.in or from CVS update.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: config.in

[Richard Stallman]

    |> Ordinary make has to fix the timestamps too, and touch the generated
    |> files, when you are building from CVS.  It should not attempt
    |> to run autoconf unless the user says `make configure' or `make config.in'.

    In neither cases the makefile caters for CVS timestamp issues at the
    moment.  Doing it right would require a script like gcc_update from the
    gcc repository, since make cannot know whether the timestamp difference
    comes from modifying configure.in or from CVS update.

If someone wants to "do it right", then by all means do so.
But unless and until that happens, we should do something simple:
Makefile.in should update configure and src/config.in
simply by touching them.

Since you made the change to update config.in automatically, could you
please do that?

Re: config.in

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

|>     |> Ordinary make has to fix the timestamps too, and touch the generated
|>     |> files, when you are building from CVS.  It should not attempt
|>     |> to run autoconf unless the user says `make configure' or `make config.in'.
|> 
|>     In neither cases the makefile caters for CVS timestamp issues at the
|>     moment.  Doing it right would require a script like gcc_update from the
|>     gcc repository, since make cannot know whether the timestamp difference
|>     comes from modifying configure.in or from CVS update.
|> 
|> If someone wants to "do it right", then by all means do so.
|> But unless and until that happens, we should do something simple:
|> Makefile.in should update configure and src/config.in
|> simply by touching them.

But I expect a simple "make" to update configure and config.in if I modify
configure.in.  If the makefile just uses touch then they stay out of
date.  This is bad.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: config.in

[Richard Stallman]

    But I expect a simple "make" to update configure and config.in if I modify
    configure.in.

All else being equal, that would be nice, but the price to be paid
(requiring everyone who builds from CVS to install Autoconf) is too
high.  We cannot have it that way.

		   If the makefile just uses touch then they stay out of
    date.  This is bad.

We will solve that problem as follows: people who edit configure.in
will check in updated versions of configure and config.in.

Since you made the change that caused the present problem situation,
would you please fix it?

Re: config.in

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

|> Since you made the change that caused the present problem situation,
|> would you please fix it?

I have now replaced the dependency on configure.in by a variable, which
can be set to FRC or configure.in to force running autoconf and
autoheader.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: config.in

[Richard Stallman]

    I have now replaced the dependency on configure.in by a variable, which
    can be set to FRC or configure.in to force running autoconf and
    autoheader.

That is a good solution.  You can make your .bashrc set the variable,
so that configure and config.in will always be updated for you.

Thanks.

Re: config.in

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

|>     I have now replaced the dependency on configure.in by a variable, which
|>     can be set to FRC or configure.in to force running autoconf and
|>     autoheader.
|> 
|> That is a good solution.  You can make your .bashrc set the variable,
|> so that configure and config.in will always be updated for you.

This won't work, because make does not override makefile variable from the
environment by default.  What people can do, however, is to run `make
MAINT=configure.in' when they modify configure.in to get things rebuilt.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: config.in

[Richard Stallman]

    This won't work, because make does not override makefile variable from the
    environment by default.

It doesn't?  I recall that it did.  Did we change this 14 years ago?
Anyway, the default value specified in the Makefile could substitute
an envvar--then it would let you control it with an envvar.

Re: config.in

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

|>     This won't work, because make does not override makefile variable from the
|>     environment by default.
|> 
|> It doesn't?  I recall that it did.

Only if they are not explicitly set in the makefile, or you use "make -e".

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: config.in

[Kim F. Storm]

Andreas Schwab <schwab@suse.de> writes:

> Richard Stallman <rms@gnu.org> writes:
> 
> |>     I have now replaced the dependency on configure.in by a variable, which
> |>     can be set to FRC or configure.in to force running autoconf and
> |>     autoheader.
> |> 
> |> That is a good solution.  You can make your .bashrc set the variable,
> |> so that configure and config.in will always be updated for you.
> 
> This won't work, because make does not override makefile variable from the
> environment by default.  What people can do, however, is to run `make
> MAINT=configure.in' when they modify configure.in to get things rebuilt.

I'll repeat my proposal that you write a brief INTRO_CVS file explaining
the various things that you can / must do to build from CVS.

++kfs

Re: config.in

[Richard Stallman]

    I'll repeat my proposal that you write a brief INTRO_CVS file explaining
    the various things that you can / must do to build from CVS.

I think this is a good idea--who wants to do it?
I am not sure I know all the things that need to be done
when building from CVS the first time.

Re: config.in

[Pavel Janík]

   From: Miles Bader <miles@gnu.org>
   Date: 17 Apr 2002 03:45:05 +0900

   > Of course, we _should_ do the right thing and remove it from CVS (along
   > with `configure' for that matter)....

I have read the whole thread and see ideas from both sides. There are
valid arguments on both sides.

My opinion is:

   - development version will not contain any generated files, because
     they only cause troubles and are of no use for developers
   - if users of CVS miss those files, I think it is much better to
     auto-generate daily snapshots of CVS for them

   - having autogenerated files is really important for (and before)
     release
   - when creating branch for a release, we will check files that
     got generated

What do you think?
-- 
Pavel Janík

C- and M- pedals - anybody thought about that?
                  -- Martin Guertler in gnu.emacs.help

Re: config.in

[Eli Zaretskii]

> From: Pavel@Janik.cz (Pavel =?iso-8859-2?q?Jan=EDk?=)
> Date: Wed, 17 Apr 2002 14:30:41 +0200
> 
> My opinion is:

Let me give you feedback.  Please don't take this as a rebuttal; I've
spoken my views, so you know what they are.

>    - if users of CVS miss those files, I think it is much better to
>      auto-generate daily snapshots of CVS for them

Snapshots are A Good Thing, but someone will have to volunteer to do
the job of either generating them manually or (preferably) automating
their generation on gnu.org machines.  If no one volunteers, snapshots
will remain a pipe dream, and we cannot count on them to solve any
problems.

>    - having autogenerated files is really important for (and before)
>      release
>    - when creating branch for a release, we will check files that
>      got generated
> 
> What do you think?

Issues that need IMHO to be addressed (until and unless there are
snapshots):

  - what do we offer users of non-Posix platforms who use CVS?

  - how do we make sure the versions of Autoconf and related tools
    installed on the machines where the CVS version is built are
    compatible between all the developers?

Re: config.in

[Pavel Janík]

   From: "Eli Zaretskii" <eliz@is.elta.co.il>
   Date: Wed, 17 Apr 2002 17:43:49 +0300

   > Let me give you feedback.  Please don't take this as a rebuttal; I've
   > spoken my views, so you know what they are.

Of course.

   > Snapshots are A Good Thing, but someone will have to volunteer to do
   > the job of either generating them manually or (preferably) automating
   > their generation on gnu.org machines.  If no one volunteers, snapshots
   > will remain a pipe dream, and we cannot count on them to solve any
   > problems.

I prefer automatic generation of snapshots. The script should do about the
same you do for a release. Colin volunteered.

   > Issues that need IMHO to be addressed (until and unless there are
   > snapshots):

[...]

I think we can stay with the current status until the snapshot generation
is finished.
-- 
Pavel Janík

No matter how hard you try, you can't make a baby in much less than
9 months. Trying to speed this up *might* make it slower, but it won't make
it happen any quicker.
                  -- RFC1925: The Twelve Networking Truths

Re: config.in

[Richard Stallman]

We must keep configure in CVS.
Otherwise it will be too inconvenient for many users to build from CVS.

The same goes for config.in, unless the other files which are in CVS
are sufficient to build config.in without using Autoconf.

Re: config.in

[Richard Stallman]

    Of course, we _should_ do the right thing and remove it from CVS (along
    with `configure' for that matter)....

Then anyone who wants to build Emacs from CVS has to install the
latest Autoconf.  That would be quite unfortunate.

Would having an autogen.sh file prevent this problem for config.in?
If so, that would be ok.  But we still want to have the configure file
in CVS.

Re: config.in

[Eli Zaretskii]

> Date: Wed, 17 Apr 2002 10:05:13 -0600 (MDT)
> From: Richard Stallman <rms@gnu.org>
> 
> Would having an autogen.sh file prevent this problem for config.in?

IIRC, autogen.sh invokes Autoconf and Automake.

Re: config.in

[Colin Walters]

On Wed, 2002-04-17 at 13:13, Eli Zaretskii wrote:
> > Date: Wed, 17 Apr 2002 10:05:13 -0600 (MDT)
> > From: Richard Stallman <rms@gnu.org>
> > 
> > Would having an autogen.sh file prevent this problem for config.in?
> 
> IIRC, autogen.sh invokes Autoconf and Automake.

Correct.

I volunteer to implement snapshots, if we do decide to make this change.

Re: config.in

[Pavel Janík]

   From: Colin Walters <walters@verbum.org>
   Date: 17 Apr 2002 13:40:08 -0400

Hi Colin,

   > I volunteer to implement snapshots, if we do decide to make this change.

great. Please contact savannah-hackers to make this feature generic so it
could be used for all projects there.
-- 
Pavel Janík

Choose variable names that won't be confused.
                  --  The Elements of Programming Style (Kernighan & Plaugher)