[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Autoreconfing guide



+++ Henrique de Moraes Holschuh [2014-07-18 19:55 -0300]:
> On Fri, 18 Jul 2014, Wookey wrote:
> > +++ Russ Allbery [2014-07-15 23:55 -0700]:
> > > Yavor Doganov <yavor@gnu.org> writes:
> > > 
> > > > I also wonder why debian/autoreconf is needed given that autoreconf
> > > > is recursive.
> > > 
> > > I don't think autoreconf can always figure out what to do when the files
> > > are buried in some random subdirectory without anything at the top level.
> > 
> > Correct. It's generally when the source is in a subdir and there is
> > nothing autotooly at all at the top level. Or when the package
> > effectively contains two separate autoconf source trees in it.
> 
> Indeed.  In most cases, there will be a shell script somewhere (one of the
> usual names is "autogen.sh") that will call autoreconf with the appropriate
> options.
> 
> > level. I don't know if it's possible to explain this layout to
> > autotools, or if it's just something we should be telling upstream to
> > stop doing? (I've been dealing with it by backing-up
> 
> Well, as long as there is an "autogen.sh"-style script somewhere in the
> build tree that does this...
> 
> We ought to document locating and using these autogen scripts as a preferred
> substitute to running autoreconf directly (this assumes upstream does use
> the autogen script :-p).  There is no way to automate adding this to the
> package, you have to customize debian/rules in a case-by-case basis, though.

I'd like to have some info on when to use an upstream autogen.sh vs
autoreconfing (possibly with options). The one instance I've seen of a
package where the maintainer used the upstream-supplied autogen.sh
didn't work well at all (FTBFS on new arches), whilst autoreconfing
_and_ dh-autotools-deving worked fine. That was libgc which was an
interesting case:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732349
and most relevantly:
https://lists.debian.org/debian-devel/2014/04/msg00459.html

I forget exactly why the autogen.sh in that package wasn't
sufficient/correct, but my understanding is that autogen.sh is usually
designed to set up the package for a developer to build from a fresh
VCS checkout, which may not be quite the same as setting up a released
'tarball' to build on the current system. ('maintainer mode',
etc). But my understanding is vague here.

This is all the stuff that needs writing down in comprehensible form
for baffled maintainers.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


Reply to: