Henrique de Moraes Holschuh <hmh@debian.org> writes:
> Attached you'll find the new README.Debian file of the autotools-dev
> package. Any comments/suggestions/fixes?
Sure ... <g>
> The config.guess and config.sub files, used by autoconf- and automake-
> generated scripts, need to be constantly updated to address new architectures.
[...]
> Please read this file throughoutly before you package something that uses GNU
> config/autoconf.
My experience is that by far not all packages that use
autoconf/automake need config.{sub,guess}. AFAIK the rule is, that you
need config.{sub,guess} if you use one or more of:
(a) libtool
(b) AC_CANONICAL_HOST
(c) AC_CANONICAL_SYSTEM
Packages that don't build a shared lib, and have no pressing need to
know the GNU system triplet need not to worry about these issues at
all.
I think you should mention that fact in the README. I was worried for
some time why my own projects did not include these files, and whether
I should add them manually.
> By inserting some code in the debian/rules file (the clean target is the best
> place for this, as it guarantees the updated files will make it to the source
> package when dpkg-buildpackage is run), the whole process can be safely
> 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
"automake --force" (or similar) in that place instead of copying
config.{sub,guess} files "by hand" will not only introduce another
dependency, it will break horribly when autoconf/automake change
incompatibly (as has happend with automake 1.5 entering sid ATM).
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.
> No, you should not simply call ./configure with the proper prefix
> and package-dependent options and be done with it (regardless of the
> fact that just about all Debian packages do so, including some of
> mine until a few hours ago :P).
I don't think omitting --build and --host in packages that have no
config.{sub,guess} (see above) is wrong. Why should it be?
OTOH, it does no harm on these, so adding that to all packages is no
problem. Have you filed wishlists on dh_make and similar utilities so
they generate rules files with this?
> YOU STILL NEED AN UP-TO-DATE config.sub FILE TO AVOID BREAKAGE IN NEW
> ARCHITECTURES, EVEN WITH THIS SETUP.
As Steve pointed out config.guess is superflous if you give --build
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].
* 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.
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.
Did I miss some detail, or could that work out?
Footnotes:
[1] Well, this could depend on some switch or environment variable
so that building outside debian/rules would still throw an error.
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-".
--
Robbe
Attachment:
signature.ng
Description: PGP signature