Xavier de Gaye added the comment: > This approach will not work with a "multiarch" enabled environment, and break > cross builds on Debian and Ubuntu.
No, the patch does not break cross builds on Debian and Ubuntu, unless you can demonstrate it does. > Afaics, the proposal assumes that the python executable for the target > architecture is installed (which it is not for the multiarch cross-build > layout), and that each target architecture has to be identified by it's own > directory tree (again, not in the multiarch environment, you can install > multiple targets into the same path). No, you are mistaken, the path name of the build tree may be used to cross build third-party extension modules as stated in case a) of msg281993, and this should also work with debian. BTW the same code is run to cross build a standard library extension module and a third-party extension module, and obviously python is not yet installed by the time the standard library extension modules are built ;-) > The idea here is to use the platform identifier which we already had in the > trunk before the PLATDIR was removed (the multiarch id or if not defined the > platform). So by having a <target> specifier, you could deduce a path, or a > <target>-python-config executable and you're done. No need to know about a > path directly. Of course python cross builds would have to install the > <target>-python-config executable or symlink. It is not clear why, because debian has this multiarch design, this should constrain our build system to follow their paradigm. After all, debian has already found some ways to cross-build the extension modules for their supported multiarch platforms since it is not possible, as of today, with upstream CPython. > Minor issue: please s/xbuild/cross_build/. Agreed. > > * The sysconfigdata file name was terminated with a dangling > > underscore when 'multiarch' is not defined. > > That only solves part of the problem in that the kernel/os version gets > encoded as well, e.g. gnukfreebsd9, gnukfreebsd10, which is nasty when the > version of your runtime and build time kernel differ. No idea what is the problem you are refering to. It cannot be the "dangling underscore" problem since this is a cosmetic issue. Please explain. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28833> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
