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

Re: Bug#180128: state of integration of dpkg-cross into dpkg

On Sun, 22 Jul 2012 19:23:44 +0200
Guillem Jover <guillem@debian.org> wrote:

> On Sun, 2012-07-22 at 18:01:05 +0100, Wookey wrote:
> > 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”).

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

That sounds like a very useful goal. Thanks.

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

I'd be happy if this bug is closed with an upload of dpkg which extends
the cputable data to complete the ABI declarations with the
architecture-specific values from which dpkg-cross / replacement can
derive the cache values.


Neil Williams

Attachment: pgpV8kXLhsFRL.pgp
Description: PGP signature

Reply to: