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

Re: Outdated GNU config (config.{sub,guess}) and autotools-dev



Hi Bill,

On Wed, 25 Jul 2001, Bill Allombert wrote:

> I have lacked time to read debian-devel in the last few weeks, so sorry if I
> missed some points.

> I think Debian packages does not need config.guess and config.subi to build.
> Just configure packages in debian/rules with

> ./configure --host=$DEB_HOST_GNU_TYPE

> and you skip the use of config.guess.

Hmm. Yes, this is an interesting solution to that part of the question.  It
does mean that debian/rules will need to be structured such that
$DEB_HOST_GNU_TYPE is made available even when not being called from
dpkg-buildpackage, but this is good practice anyway.

> This is a clean definitive solution, without kludge, and this follows policy
> 12.1. And more important, it protext ourself against sub-architecture
> optimisation (we don't want i386 package build on pentium machine to use
> pentium specific instruction). (for example I dont like gdb to say
> This GDB was configured as "i686-pc-linux-gnu".
> because really it should be configured for  "i386-pc-linux-gnu"
> (which is equivalent of course, but only by chance)).

True.  The macros included in rpm take care of this automatically for that
platform so that 'optimizations' aren't enabled accidentally, but we seem to
not have such protection when building debs -- that is to say, most people
don't make use of it.


> For config.sub, it is a bit more subtle, because we cannot avoid configure
> to call it easily.


> # Check  for Debian architecture
> if [ "x$DEB_HOST_GNU_TYPE" = "x$1" ] then
>   echo "$DEB_HOST_GNU_CPU-unknown-$DEB_HOST_GNU_SYSTEM-gnu"
>   exit 0
> fi

> This way, when config.sub is updated, the patch will apply cleanly.

An interesting suggestion.  I'm trying to decide if I like this idea. :)  Of
course, if other options prove impossible due to licensing restrictions, this
is not the worst alternative to present itself.  The limitations I do see are
that it requires maintainers to patch scripts they may not understand well
themselves, and that it takes control away from config.sub regarding what
constitutes a 'canonical' host type.

Steve Langasek
postmodern programmer



Reply to: