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

[RFC] GNU autoconf and dpkg-architecture

I've just noticed something while writing documentation for autotools-dev,
and it is something I would like the input of more developers before making
up my mind about how to act on it.

The manpage of dpkg-architecture states:
       The environment variables set by dpkg-architecture are passed to
       debian/rules as make variables (see make documentation). You can
       and should use them in the build process as needed. [...]

Debian policy states:
     You should make sure that the `configure' utility detects the correct
     architecture specification string (refer to Section 12.1,
     `Architecture specification strings' for details).
     The architectures we build on and build for are determined by `make'
     variables using the utility `dpkg-architecture'.  You can determine the
     Debian architecture and the GNU style architecture specification string
     for the build machine (the machine type we are building on) as well as
     for the host machine (the machine type we are building for). [...]

By using something like this (GNU make makefile fragment):
export DEB_HOST_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
export DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)

	./configure --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE) \
                    --prefix=/usr ...

Instead of simply letting configure run config.guess and config.sub to find
out the architecture, one gets a few benefits.

0. dpkg-buildpackage has already run dpkg-architecture and set those
   variables for you anyway, one might as well use them for something like
   Debian policy urges one to.
1. The build and host architecture are correctly set to the ones Debian
   should be using (e.g. i386-pc-linux-gnu for all ia32 machines). And
   anyone who wants to set it to something else just needs to set the proper
   environment variable.
2. config.guess is never called (a damn Good Thing)
   Less wasted CPU cycles, and one less point of failure are a Good Thing!
   One needs only to look at how the newer 2.4 kernels broke config.guess
   on MIPS to understand why (btw, have you updated your config.* crap this
   year? if not, you have the broken MIPS code in your package).
3. It looks like the Right Way to do things re. the
   almost-never-used-for-anything build and host stuff in GNU config,
   and the spirit of section 5.2 and 12.1 of Debian policy.

The question is:

Should I try to get the above way of calling configure to be the "do it
unless you know damn well you need to do it differently" way of doing things
in all Debian packages that use GNU autoconf?  

This means raising the awareness of the issue by sending an email to
d-d-announce (due to the massive number of packages this issue addresses),
for example.  Therefore, I am bringing this up here in d-devel first.

Comments, please?

  "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: