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

Re: [RFC] GNU autoconf and dpkg-architecture

On Fri, 08 Feb 2002, Manoj Srivastava wrote:
> >>"Marcus" == Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
>  Marcus> For autoconf2.52 and later: (this is WRONG for older autoconf)
>  Marcus> For autoconf 2.13: (this will generate a warning
>  Marcus> if used with autoconf 2.52, but will still work until autoconf 3)
>  Marcus> For I-don't-care-and-don't-know-what-I-am-doing: (might not
>  Marcus> work for some packages) 
>  Marcus> confflags += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE)
>  Marcus> The last one is safe autoconf-wise (works with any version),
>  Marcus> but might not be safe package-wise (some older packages might
>  Marcus> choke on the build arch being specified).
> 	So what are we supposed to do then? grep for the autoconf
>  version that generated the configure script in the rules?

My current recomendations for this are:

1. The package does not run autoconf at build time (because you know better
than to do something like this, and engineered the package to make sure it
does not happen)

  1a. The package does not do anything special to the arch stuff (99.9% of
      the packages should fall here in an ideal world), or uses autoconf

      Use the "I-don't-care-and-don't-know-what-I-am-doing" solution, it
      is the correct solution for 2.52+, and it works fine with 2.13.

  1b. The package uses autoconf 2.13 and uses the arch stuff
      Use the autoconf 2.13 solution, and comment it so that you will
      remember to update it if the package switches to 2.52+

2. The package runs autoconf during the build (please consider changing
      the package so that (1) above applies. See autotools-dev readme
      for hints on how to do that).

  2a. The package works with autoconf 2.52 (and maybe 2.13 too)
      Build-depends on autoconf (>=2.52), let 2.13 rot in hell.
      Use the "I-don't-care-and-don't-know-what-I-am-doing" solution, it
      is the correct solution for 2.52+.  If that doesn't work fine, there
      is a very bad bug in your configure.in script. Fix it.

  2b. The package only works on autoconf 2.13

      Build-depends on autoconf2.13, and do whatever else the autoconf
      maintainer tells you to do to use 2.13
      Use the autoconf 2.13 solution, and comment it so that you will
      remember to update it if the package switches to 2.52+

3. "I don't know what the package needs, and I won't look it up"

      Update config.sub and config.guess to the ones in latest sid's
      autotools-dev, don't touch anything else.
      After all, if you are not going to do it right, don't do it.

> ======================================================================
> AUTOCONF_VERSION:=$(shell grep "Generated automatically using autoconf" \
>                     configure | sed -e 's/^.*autoconf version //g')
> HAVE_NEW_AUTOMAKE:=$(shell if [ $(AUTOCONF_VERSION) -ge 2.13 ]; then \
>                              echo 'YES' ; fi)
> ifneq($(strip $(HAVE_NEW_AUTOMAKE)),)
> confflags += --build $(DEB_BUILD_GNU_TYPE)
>   confflags += --host $(DEB_HOST_GNU_TYPE)
> endif
> else
>    confflags += $(DEB_HOST_GNU_TYPE)
> else
>    confflags += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE)
> endif
> endif
> ======================================================================
>    Or something like that? This is painful in the extreme.

I agree. This crap should not change again for a LONG time (since it is now
sane in 2.52, at last), there is no reason to go around overengineering
this. Autoconf 2.52 states that it will compare --build and --host, and
enter crosscompiling mode only if they differ. 

2.13 did not state this, but unless you have a weird system (normal Debian
installs will not cause trouble) or an in-need-to-update 2.13 configure.in
that actually cares, specifying both --host and --build is ok.

Now I need to check and make sure libtool does not have any sort of
drainbramage over the cross-compiling config stuff either, and do a
find-the-broken-packages run on lintian.debian.org.

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Reply to: