Am 19.12.2012 21:30, schrieb Barry Warsaw: > On Dec 19, 2012, at 12:50 PM, Jakub Wilk wrote: > >> * Barry Warsaw <ba...@python.org>, 2012-12-14, 16:29: >>> ++dnl Debian multiarch support in sys.implementation._architecture >>> ++dnl Try `dpkg-architecture -qDEB_BUILD_MULTIARCH` first, then ++dnl >>> `gcc --print-multiarch`. ++AC_SUBST(MULTIARCH_BUILD) >>> ++AC_CHECK_PROG(HAS_DPKG_ARCHITECTURE, dpkg-architecture, found, >>> not-found) ++if test $HAS_DPKG_ARCHITECTURE = found ++then ++ >>> MULTIARCH_BUILD="dpkg-architecture -qDEB_BUILD_MULTIARCH" ++else ++ >>> AC_CHECK_PROG(HAS_GCC_FOR_ARCH, gcc, found, not-found) ++ if test >>> $HAS_GCC_FOR_ARCH = found ++ then ++ MULTIARCH_BUILD="gcc >>> --print-multiarch" ++ else ++ MULTIARCH_BUILD="" ++ fi >>> ++fi >> >> s/DEB_BUILD_MULTIARCH/DEB_HOST_MULTIARCH/ presumably? > > Yes, I think you're right. Thanks. > > (Does it make sense to expose the other dpkg-architecture stuff, or should > we just keep it simple?)
hard-coding gcc is wrong. you should use CC and have this code at a position where it's clear which CC to use. if this patch is debian local, you can drop the dpkg-architecture check. _architecture is a bad name. just name it _multiarch, or obfuscate it even more (a name longer than single_version_externally_managed would be preferred). Make sure that the tuple ends up in _sysconfigdata.py with a sensible name, e.g. HOST_MULTIARCH. The latter one can be overwritten for cross builds (once the 3.3 cross build changes are backported), and should be the preferred way to access this information. Matthias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
