Re: [RFC] Hits/directions to using autoconf and friends in Debian
On Sun, 14 Oct 2001, Robert Bihlmeyer wrote:
> I think you should mention that fact in the README. I was worried for
Done.
> > automated: The config.guess and config.sub files will be updated at every
> > build, then.
>
> Maybe this is the right place to caution maintainers that calling
[...]
Done.
> It is GNU philosophy to distribute the autotools-generated files with
> the source, so the autotools upstream maintainers are not that careful
> about backwards compatibility.
Indeed. Same goes for gettext and libtool...
> I don't think omitting --build and --host in packages that have no
> config.{sub,guess} (see above) is wrong. Why should it be?
It isn't, but as you said, it is not wrong to always include them either...
> problem. Have you filed wishlists on dh_make and similar utilities so
> they generate rules files with this?
There's a bug against dh-make already. One needs to be filled against
debmake.
> and --host. Actually, we could make config.sub largely superflous,
> too, and solve this whole mess once and for all. Or so I think -- the
> plan is:
>
> * Patch config.sub so that it just passes through unknown triplets,
> i.e. "config.sub foo-bar-baz" will output "foo-bar-baz" not error
> out as it does right now[1].
That would not be acceptable. It opens a dangerous can of worms.
> * All packages that need config.{sub,guess} must either update them on
> build, or, preferrably, include a config.sub that worked as above,
> and use --build and --host in their configure call.
They should use --buind and --host because that saves on a very
CPU-expensive call to config.guess in the autobuilders.
> This would ensure that they build fine even on not-yet-known
> architectures, because dpkg-architecture would (by definition) give
> the correct, canonical designation there. config.sub would perhaps not
> recognize it, but since it is already canonical, passing it through is
> the Right Thing.
Well, right now dpkg-architecture fails to output the proper canonical
GNU architecture :(
> On a related note, config.sub already exhibits this behaviour if we
> feed it a $ARCH-unknown-$OS triplet. This will be the canonical
> triplet anyway execept for ARCH i386 or mips (where the "unknown" part
> is "pc" or "mips" respectively). So we may get away with stock
> config.sub when we ensure that future platforms canonical names will
> include "-unknown-".
Now, that one is a very helpful hint. I'll ask GNU config upstream about
that, and if it is something we can count upon not to break in the future,
it looks like you found the way to go.
--
"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: