On Fri, 13 Feb 2009 12:29:53 +0000 Wookey <wookey@wookware.org> wrote: > > > e.g. in etch: > > > Depends: libc6-dev | libc-dev, gcc (>= 4:4.1.1), g++ (>= 4:4.1.1), make, > > > dpkg-dev (>= 1.13.5) > > > > > > Now for cross-building that's not really what you want. > > > > Why? If you're thinking that the build should fail if any process calls > > gcc and not $triplet-gcc, then maybe - but that won't work for all > > packages (see CC_FOR_BUILD below). Instead, we already have a lintian > > check that will parse the architecture of the actual binaries that end > > up being packaged and fail if these do not match the claimed > > architecture of the package itself. Yes, this only fails the completed > > build but we do need gcc in a cross-building chroot, sadly. > > Hmm. I was thinking of the case where you are making a 'pure' > cross-toolchain chroot; I have just made a set of 4 > (i386/amd64-etch/lenny). I know that none of the packages I need to > build have annoying native-toolchain dependencies so a native gcc is > not required. Thus it would be nice to have a crossbuild-essential > package to make installing this sort of thing easier. > > Packages that _also_ depend on a native toolchain imply the need for > build-essential. Unfortunately nothing in the dependencies gives us > this info - I think we should try to invent something that does (in > xcontrol). Good idea. As you mentioned, these packages are the exception so it does make sense to treat them as exceptions. > I was just thinking of a virtual package (like mail-transport-agent). > So any cross-toolchain provides gcc-cross. Trying to include all the > existing arches/version as alternatives explicitly is a bad idea. > particular toolchains could also provide a virtual gcc-$triplet-cross > so 4.1,4.2,4.3 would all satisfy for people who don;t particularly > care which they have (in practice I never have yet, since the C++ ABI > settled down in gcc3.3 OK. > In general these packages are the exception rather than the rule and > I'd like to bear that in mind when designing mechanisms. If we can > flag these then we can deal with them - that's the problem to think > about. I'll be flagging all such packages currently in Crush during the Code Audit and hoping to get relevant fixes into the Debian packages. This could include the addition of the xcontrol file with an appropriate line indicating that the package needs a native compiler as well as a cross-compiler. We could simply re-use Build-Depends-Tools: by adding build-essential to the list of tools to be installed, only in xcontrol. Simon? -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpR5mcUP2faz.pgp
Description: PGP signature