Re: Managing changes to configure.in as patches
Quoting Wouter Verhelst <wouter@grep.be>:
> Op wo 07-01-2004, om 13:57 schreef Daniel Kobras:
> > On Wed, Jan 07, 2004 at 01:36:25PM +0100, Jérôme Marant wrote:
> > > I'm trying to find a good way to manage changes to configure.in
> > > as patches.
> > > Until now, running aclocal, autoconf and others from debian/rules
> > > was considered as a bad practice. So, people run them manualy out
> > > of the debian packaging.
> > >
> > > However, doing like this is annoying especialy when changes to
> > > configure.in go with some changes to source files: I'd like to
> > > keep everything in a single (d)patch.
> >
> > I usually split it up into two dpatches: eg. 10_foo.dpatch containing all
> > the manual changes, including those to Makefile.am, configure.in etc.,
> > and a 11_foo_fixup.dpatch comprising of the auto-generated changes to
> > Makefile.in, configure etc. Works quite well, and keeps interesting and
> > boring parts apart.
>
> As an added bonus, this also fixes the issue with patching
> autotools-related files: since patch does not care about timestamps, if
> you create one patch with changes to both configure.in and configure,
> you may end up with a configure.in which has a more recent mtime than
> it's related configure, especially on the slower architectures,
> resulting in automake trying to regenerate it. If you put them in two
> distinct patches and ensure the autogenerated files are patched after
> the source files, as you suggest, then configure cannot have a more
> recent timestamp than configure.in (of course, the same applies to
> Makefile.in vs Makefile.am, and so on).
This seems a very good idea to me. Thanks Daniel and Wouter!
Cheers,
--
Jérôme Marant
Reply to: