submitting patches to configure.in -- include results of aclocal/autoconf/autoheader/automake?

submitting patches to configure.in -- include results of aclocal/autoconf/autoheader/automake?

[Adam Megacz]

When submitting a patch to a configure.in file, should the submitter
include diffs of the changes to other files (Makefile.in, etc), or
will the maintiner who commits it to cvs re-run
aclocal/autoconf/autoheader/automake before doing a cvs commit?

  - a

Re: submitting patches to configure.in -- include results of aclocal/autoconf/autoheader/automake?

[Andreas Jaeger]

Adam Megacz <gcc@lists.megacz.com> writes:

> When submitting a patch to a configure.in file, should the submitter
> include diffs of the changes to other files (Makefile.in, etc), or
> will the maintiner who commits it to cvs re-run
> aclocal/autoconf/autoheader/automake before doing a cvs commit?

You don't commit them - but add in your ChangeLog entry that those
are regenerated and mention it in your email so that the committer
does it,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: submitting patches to configure.in -- include results of aclocal/autoconf/autoheader/automake?

[DJ Delorie]

> When submitting a patch to a configure.in file, should the submitter
> include diffs of the changes to other files (Makefile.in, etc), or
> will the maintiner who commits it to cvs re-run
> aclocal/autoconf/autoheader/automake before doing a cvs commit?

When you post a patch to the mailing lists for approval, IMHO you
don't need to include diffs for the regenerated files.  The reviewer
can regenerate them if they really want to know what the changes are.

However, *you* should look at those diffs, to make sure that you
aren't accidentally using the wrong version of the tools and thus are
causing unexpected unrelated changes to the generated files.

Of course, whoever checks in the .in files (you or the maintainer)
must check in freshly regenerated files that go along with it also.