Bug#698765: dh-autoreconf: document handling of packages that only use Autoconf plus config.{guess,sub}
Colin wrote: but no doubt more sensible examples exist zsh appears to be one such package just doing configure: dh_autoreconf dh_autotools-dev_updateconfig clean: dh_autotools-dev_restoreconfig dh_autoreconf_clean works fine for that package. I'd expect that to usually work if the build isn't too fancy. BTW I think you typoed your example above: cp -f /usr/share/misc/config.guess /usr/share/misc/config.guess ./ should be: cp -f /usr/share/misc/config.sub /usr/share/misc/config.guess ./ Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698765: dh-autoreconf: document handling of packages that only use Autoconf plus config.{guess,sub}
So maybe not the original issue, however I see dh-autoreconf running for an hour
or more on a slow platform, even if I know that all the updates I need are
config.{guess,sub} files only.
Sure, that could be misuses of dh-autoreconf, but it's annoying ...
The other thing I start disliking about dh-autoreconf is, that this b-d probably
will never be removed again, even if the autoconf files are updated upstream.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698765: dh-autoreconf: document handling of packages that only use Autoconf plus config.{guess,sub}
On Sat, Jul 20, 2013 at 11:42:03AM +0200, Matthias Klose wrote:
So maybe not the original issue, however I see dh-autoreconf running for an
hour
or more on a slow platform, even if I know that all the updates I need are
config.{guess,sub} files only.
Sure, that could be misuses of dh-autoreconf, but it's annoying ...
I don't consider that to be a misuse. I find dh-autoreconf immensely
valuable for reasons other than config.{guess,sub} updates; for example
consistently using it makes it much simpler to patch Autotools source
files.
--
Colin Watson [cjwat...@debian.org]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698765: dh-autoreconf: document handling of packages that only use Autoconf plus config.{guess,sub}
Package: dh-autoreconf
Version: 7
Severity: wishlist
dh-autoreconf(7) says:
dh_autoreconf is a superset of the autotools-dev debhelper addons, so
you do not need --with=autotools_dev if you use --with=autoreconf. In
fact, in most cases they should not be used together, as it may lead
to unpredictable behaviour.
For the most part, I agree. However, there is one not entirely uncommon
situation where dh_autoreconf is not in fact a superset of the
autotools-dev add-ons. autoreconf doesn't update config.guess and
config.sub directly, but only (as far as I know) by way of automake and
possibly libtoolize. If you have a package that only uses Autoconf and
not Automake or Libtool, but that does use the AC_CANONICAL_* macros (I
have one such, admittedly the joke package vigor, but no doubt more
sensible examples exist), then dh_autoreconf will not update
config.{guess,sub} but dh_autotools-dev_updateconfig will. It's
therefore not strictly true to say that the former is a superset of the
latter.
It took me a while to figure out what was going on, and I know the
autotools fairly well, so I think it would be worth documenting this
situation. I tend to agree that combining dh_autoreconf and the
autotools-dev add-ons is rather confusing, although I suspect it could
be made to work with some care. My approach was to build-depend on
debhelper (= 7.0.50~), dh-autoreconf, autotools-dev, and then put
this in debian/rules (actually I did something slightly different in
vigor because its configure lives in a build/ subdirectory, but it would
be better to document a more common case):
autoreconf:
autoreconf -f -i
cp -f /usr/share/misc/config.guess /usr/share/misc/config.guess ./
override_dh_autoreconf:
dh_autoreconf debian/rules -- autoreconf
Perhaps it would be worth adding something along these lines as an
example, to help out the next developer who runs into this?
Thanks,
--
Colin Watson [cjwat...@debian.org]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698765: dh-autoreconf: document handling of packages that only use Autoconf plus config.{guess,sub}
Control: tag -1 confirmed
On Wed, Jan 23, 2013 at 11:29:19AM +, Colin Watson wrote:
Package: dh-autoreconf
Version: 7
Severity: wishlist
dh-autoreconf(7) says:
dh_autoreconf is a superset of the autotools-dev debhelper addons, so
you do not need --with=autotools_dev if you use --with=autoreconf. In
fact, in most cases they should not be used together, as it may lead
to unpredictable behaviour.
For the most part, I agree. However, there is one not entirely uncommon
situation where dh_autoreconf is not in fact a superset of the
autotools-dev add-ons. autoreconf doesn't update config.guess and
config.sub directly, but only (as far as I know) by way of automake and
possibly libtoolize. If you have a package that only uses Autoconf and
not Automake or Libtool, but that does use the AC_CANONICAL_* macros (I
have one such, admittedly the joke package vigor, but no doubt more
sensible examples exist), then dh_autoreconf will not update
config.{guess,sub} but dh_autotools-dev_updateconfig will. It's
therefore not strictly true to say that the former is a superset of the
latter.
I wonder why autoreconf does not just update config.guess/config.sub
if it detects an AC_CANONICAL_* MACRO.
It took me a while to figure out what was going on, and I know the
autotools fairly well, so I think it would be worth documenting this
situation. I tend to agree that combining dh_autoreconf and the
autotools-dev add-ons is rather confusing, although I suspect it could
be made to work with some care. My approach was to build-depend on
debhelper (= 7.0.50~), dh-autoreconf, autotools-dev, and then put
this in debian/rules (actually I did something slightly different in
vigor because its configure lives in a build/ subdirectory, but it would
be better to document a more common case):
autoreconf:
autoreconf -f -i
cp -f /usr/share/misc/config.guess /usr/share/misc/config.guess ./
override_dh_autoreconf:
dh_autoreconf debian/rules -- autoreconf
I think that using the autotools-dev add-on together with dh-autoreconf
should work in such a case as well (using them together is only problematic
if autoreconf changes config.{guess,sub}; otherwise it should just
work). Although that solution works just as well.
Perhaps it would be worth adding something along these lines as an
example, to help out the next developer who runs into this?
Absolutely.
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
