Re: Bug#180128: state of integration of dpkg-cross into dpkg
Hi!
On Sun, 2012-07-22 at 18:01:05 +0100, Wookey wrote:
> +++ Neil Williams [2012-07-22 17:05 +0100]:
> > On Wed, 18 Jul 2012 19:11:38 +0200
> > Guillem Jover <guillem@debian.org> wrote:
> >
> > > So, was checking this (and also the dpkg roadmap) and was wondering what
> > > else is still missing to be merged from dpkg-cross? If the only problem
> > > is the listed below, then it'd seem this bug has been resolved and it
> > > can be closed.
> >
> > One unresolved issue is the cache values and architecture support:
> > where to put the cross- config settings currently implemented
> > in /etc/dpkg-cross/cross* which pass the architecture-specific values
> > to autotools projects. CC'ing debian-embedded for more input on
> > that.
>
> > The rest of this problem comes down to individual packages:
> >
> > 0: packages using custom config scripts instead of pkg-config
> >
> > 1: packages which have m4 macros which don't handle cross-building
> > cleanly, e.g. AC_TRY_RUN without fallbacks.
>
> It was sugested at the multiarch-cross BOF at debconf this year that we
> create a 'crossbuild-support' package to take over these various glue
> functions from dpkg-cross. That could just stay named 'dpkg-cross' for
> simplicity but if we are going to drop all the cross-conversion
> functionality and add a load of other stuff, a name change makes
> sense.
Such package sounds like a good idea indeed, but I'd really like if any
glue required there would end up being mere environment variable
settings (like appropriate CC for cross-building for example), symlinks
for cross tools, the cache files or at most a tiny wrapper for
dpkg-buildpackage passing correct options. Anything else should be
integrated back in the lower layers IMO (if it makes sense and the
solutions are “generic enough”).
> > Therefore, I think this bug will need to remain open, unless dpkg
> > maintainers do not wish to integrate the cross architecture-specific
> > metadata at all. (This data does not change until a new port is
> > accepted by dpkg or an old port removed, at which point it is just a
> > single file addition/removal containing data provided by the porters.)
> > e.g. for armel:
> > ac_cv_c_bigendian=no
> > ac_cv_c_char_unsigned=yes
> > ac_cv_sizeof_long_long=8
> > ac_cv_sizeof_unsigned_long_long=8
> > ac_cv_sizeof_long=4
Something that has crossed my mind in the recent past is that cputable
has most of this data, but not all, and it could make sense to add
more information so that the architecture ABI is crystal clear from
the tables alone. dpkg-cross or crossbuild-support or whatever could
then generate an autoconf cache file at build time from the dpkg tables
for example. Because I'd assume there's other cached values that will
end up there and those would certainly not be appropriate for dpkg.
> I don't think that dpkg is the right place for this data. We want to
> be able to update it easily without having to mess with important
> things like dpkg. The core cross functionality is now in dpkg and apt.
> We should discuss where remaining stuff like autoconf cache variables,
> triplet-prefixed commands like <triplet>-pkg-config and
> <triplet>-config scripts, cross-build-essential package lists and the
> like should live, but I don't currently see good arguments to put any
> more of it into dpkg.
Except for my comments above, I tend to agree with this.
thanks,
guillem
Reply to: