Re: [multiarch] Proposal for *-dev packages
Daniel Kobras <email@example.com> writes:
> On Wed, Jan 14, 2004 at 09:32:18PM +0100, Goswin von Brederlow wrote:
> > Daniel Kobras <firstname.lastname@example.org> writes:
> > > How to include arch-specific information that is probed at configure
> > That would be either static information that can be gathered once and
> > hardcoded into the headers or its information particular to the buildd,
> > which should never make it into the -dev package.
> So before I upload a new library package I log into 11+ architectures,
> run configure, compare headers and patch in the diffs wrapped in #ifdef
> <ARCH_FOO>. Sure, I can do that as long as you don't mind me cursing you
> to hell and back along the way. 'find /usr/include -name "*config.h"'
> should get you a rough idea of the magnitude of this problem, by the way.
Rename libfoo-dev to libfoo-arch-dev and have lib-foo-dev depend on
the right set of specific debs. Is that better?
> > > time? What about porting to new archs when there's no preprocessor
> > > conditional yet?
> > Add one to gcc first thing in the morning. Or set -D__NEW__ in the
> > compile flags.
> With __NEW__ invoking what?
> #ifdef __NEW__
> #error Architecture not yet supported
> > > Same problem here. Those scripts may contain arch-specific data, eg.
> > > arch-dependent CFLAGS.
> > There are just so many archs that can easily all be included and
> > the right one chosen at runtime.
> And how to determine what needs to go into mips CFLAGS when I'm
> packaging on x86? Not to mention Hurd or the BSDs. Those scripts are
> generated from configure for a reason. Furthermore, I don't assume such
> changes stand a chance of ever being merged upstream. I for one don't
> find the idea of dragging such cruft along in diff.gz forever appealing.
If the information comes from configure get it from configure. Don't
stick it into the headers at compile time, thats just stupid.