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

Re: automake/autoconf in build-dependencies



On Sun, Mar 13, 2005 at 12:04:59PM +0000, Henning Makholm wrote:
> Scripsit Daniel Schepler <schepler@math.berkeley.edu>
> 
> > - Putting autoconf-generated files in the source package is nearly as
> > fragile as generating them at build time.  If there are changes in
> > autoconf which break the configure.ac etc, then the next time you want
> > to make other changes or bring your changes forward to a new upstream
> > version, you'll have to fix things anyway.  This to my mind pretty
> > much reduces the "future buildability" benefits to nearly nothing.
> 
> That's a reason *contra* in my opinion.
> 
> When I include the configure script in my source packages, I can feel
> pretty confident that they package I upload will stay buildable even
> if a week from now autoconf or automake gets updated to something not
> backwards compatible.

Some arches for instance have problems with old versions of
libtool resulting in a broken configure on only those arches.
Now they have to file a bug report asking for a libtool update to
the latest (debian) version.  It _could_ be handy that such
requests weren't needed.

Note that I do understand your argument that a new version could
break.  But we do have autoconf, autoconf2.13, automake1.4,
automake1.6, automake1.7, automake1.8, automake1.9, libtool,
libtool1.4.  You can build-depend on the version that you
require.

However, I do understand that if you just build-depend on
autoconf and you suddenly have to change to autoconf2.13 because
they changed the version to 2.5x and your script doesn't work
with autoconf 2.5x you have a problem.  But sooner or later you
will have to do something about the problem anyway.  You can't
stay using autoconf2.13 for ever.  Some day that version will get
removed from the archive.  Just like libtool1.4 is already
orphaned and planned to be removed after sarge gets released.


An other argument that was only vaguely mentioned was that you
can look at configure.in/ac as source.  Some people seem to
disagree with this but I haven't seen their arguments for it.
I don't think I can agree to their arguments anyway.  The same
goes for things like bison.

We do not have a requirement that everything is build from
source, only that we should be able to do so.  But I think it's a
good idea to always build everything from sources.  If you have
to fix something, it's always going to be easier to fix in the
source.  And how can you know you can actually build it if you
never tried it?


Kurt



Reply to: