Re: [multiarch] Proposal for *-dev packages
Daniel Kobras <kobras@debian.org> writes:
> On Wed, Jan 14, 2004 at 09:32:18PM +0100, Goswin von Brederlow wrote:
> > Daniel Kobras <kobras@debian.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
> #endif
>
> ?
>
> > > 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.
>
> Daniel.
If the information comes from configure get it from configure. Don't
stick it into the headers at compile time, thats just stupid.
MfG
Goswin
Reply to: