On Tue, Aug 30, 2011 at 11:50:09PM +0100, Mikolaj Kucharski wrote:
> On Tue, Aug 30, 2011 at 11:48:24PM +0200, Matthias Kilian wrote:
> > [cc'ing ports@]
> >
> > On Tue, Aug 30, 2011 at 05:24:54PM -0400, Brad wrote:
> > > >-pre-configure:
> > > >- @cd ${WRKSRC}&& \
> > > >+post-patch:
> > > >+ @cd ${WRKSRC}&& env \
> > > > AUTOCONF_VERSION=${AUTOCONF_VERSION} \
> > > > AUTOMAKE_VERSION=${AUTOMAKE_VERSION} \
> > > > ${MAKE_PROGRAM} -f Makefile.dist
> > > >
> > >
> > > It would be nice if this stuff was standardized across the tree.
> > > There is a mix of the two targets being used throughout the tree
> > > for calling autogen.sh/Makefile.dist or whatever means of
> > > regenerating the autoconf/automake bits in a project.
> >
> > AFAIK, the standard targets (if CONFIGURE_STYLE=autoconf or automake)
> > are all tied to post-patch. So your diff is good and people maintaining
> > ports with special autoconf/automake targets should work on similar
> > diffs. That is: run autoconf and/or automake during post-patch *if*
> > you have to run it explicitely.
>
> Guys, I'm just curious, why post-patch is better than pre-configure? I
> would go for pre-configure than post-patch.
Most projects do ship a configure and a configure.ac. Also Makefile.in
and Makefile.am.
In those projects, you patch stuff, and then running autoconf and automake
again is a natural step of finishing the patches (propagating the changes
you just made into the generated files). There's also the issue of
touching the right files in the right order so that the internal
dependencies of automade Makefile don't trigger and fix you up.
For projects that *don't* ship a configure, but rely on autogen.sh or
similar, the correlation is less obvious, and there's indeed a question
of whether to run during post-patch or pre-configure.
But running everything during post-patch makes for a more consistent tree,
so it offsets the scale fairly heavily.
