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

Re: [RFC] GNU autoconf and dpkg-architecture



Hi Henrique,

On Fri, Feb 01, 2002 at 12:09:15PM -0200, Henrique de Moraes Holschuh wrote:

> Debian policy states:
> (2.4.3):
>      [...]
>      You should make sure that the `configure' utility detects the correct
>      architecture specification string (refer to Section 12.1,
>      `Architecture specification strings' for details).
>      [...]

There appears to be a disconnect between autoconf and Debian on this,
though.  The autoconf docs say (about specifying the system type):

    TYPE can either be a short name for the system
    type, such as `sun4', or a canonical name which has the form:

        CPU-COMPANY-SYSTEM

    where SYSTEM can have one of these forms:

        OS
        KERNEL-OS

whereas Debian policy section 12.1 says:

    Note that we don't want to use arch-debian-linux to apply to the
    rule architecture-vendor-os since this would make our programs
    incompatible with other Linux distributions. We also don't use
    something like arch-unknown-linux, since the unknown does not look
    very good.


I'm guessing that we get away with just "i386-linux" because the
"config.sub" script canonicalizes it for us.  Indeed, that script also
eschews "COMPANY=unknown" because 'the word "unknown" tends to confuse
beginning users'; for "i386-linux", we end up with "i386-pc-linux-gnu".

I wonder whether older versions of "config.sub" will choke on
"i386-linux"?


> 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.

Note that supplying these will only suppress running "config.guess".
The "config.sub" script is run unconditionally, to canonicalize the
build and host values.


> 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).

True, this ensures that all debian builds use, e.g. "i386" rather than
"i686".


> 2. config.guess is never called (a damn Good Thing)
>    Less wasted CPU cycles, and one less point of failure are a Good Thing!

The fraction of CPU cycles used for "config.guess" in a typical
build is surely negligible!

Having one fewer points of failure is a reasonable point.


> 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.

That's not a technical argument!  :-)

Steve Langasek's point about paving the way for cross building is
a reasonable point.


> 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?  

Sending email to d-d-announce is a fine idea.  [I personally think
that more of these "best practices" announcements would be welcomed.
For example, an announcement about the fact that packages.debian.org
understands URLs in package descriptions would be a boon.]

What do you want as the end result?  A policy change?  I don't
anticipate any harm in doing it your way, but I don't see a huge
benefit, either.  Sending mass bug reports or changing policy to force
the use of --build doesn't seem justified to me.

The main benefit that I see is #2: avoiding build failures on
relatively new machine architectures.  However, this applies only to
the relatively few packages that actually *use* the "host" value.  For
most packages, the change is only busy-work, and you risk breaking
something due to a typo.

Perhaps an effective way to deal with this (in addition to an email to
announce) is to train the buildd maintainers to point to your text
when they send a bug report on a package that failed to build because
of an old config.guess.

Cheers,
-Steve


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants



Reply to: