Dealing with autotools

[Manoj Srivastava]

On Wed, Apr 15 2009, Loïc Minier wrote:

> On Wed, Apr 15, 2009, Robert Collins wrote:
>> > Wasn't this heavily frowned upon in Debian for many years?
>> Opinions have varied.
>
>  And still do...
>
>> Absolutely; not build-deping on autotools is a fundamental mistake IMO:
>> it makes packages bigger (you have to carry a configure script delta),
>> harder to review (generated content is in the diff).
>
>  I find that running the autotools during build is fragile over time.

        In my experience, while that used to be true, it has not been
 the case for some time now. 

>  It can break in subtle ways with new autotools versions.

        Sure. But that hasn't happened to me in a couple  of years now,
 and the threat of breakage has to be measured against the advantages of
 a better build fit on a user's  machine. I don't just package for
 myself, or Debian: the software is put together for the end user to
 build themselves (isn't that what all this free software all about?),
 so running auto-tools on the machine it is to be used on has benefits.

>    Most people don't understand autotools enough to do the right
>    thing.

        I hope  developers are not in that number.

>  Most packages running autotools during build will call automake,
>  aclocal, autoconf in weird orders or lacking some additional commands
>  which their packages need -- instead of autoreconf, which might not
>  even be enough when you're using things like intltool or
>  glib-gettext.

        In the configure phase of my packages, I call the tools in the
 proper order, instead of lettting it be random chance, so this is
 mostly irrelevant. People can be taught to do things propoerly in the
 configure target.

>    Also, running autotools at runtime requires you to build-depend on all
>  tools needed by the upstream maintainer instead of just the libs you
>  need to build the features you care about; often people will miss some
>  bdeps as a result (typically when upstream doesn't ship some m4
>  macros).

        Being careful about build dependencies is one of the things
 developers do: or, at least, competent developers. There is not
 guarantee that you will not miss build dependencies even on your
 development box, you might not have all the things installed.

        I  generally study the configure file, and see what configure is
 probing for. And then I look to see if the code woul take advantage of
 the things being probed for. Then I build in a build virtual machine,
 and  compare with a similar build on my development box, and compare.

        I would think this would be standard package maintainer
 activity. 

>  In all cases, this is not black and white; I would still recommend that
>  people who aren't versed in autotools just autoreconf into a patch and
>  make sure that patched tree works well.

        I used to believe that, until around 2005-2006. Since then, I
 have done autotools at package build time, and I would strongly
 recommend my peers to do the same.

        manoj
-- 
"I do not fear computers... I fear the lack of them." Isaac Asimov
Manoj Srivastava <srivasta at acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C