This is minimal patch that add basic cross-compilation possibilities for
python build (configure script).

The patch add macro AC_CANONICAL_HOST.
This macro require files config.guess, config.sub. The patch don't
include them. You may obtain them from GNU automake tarbal.

As result of macro new variable $host ("host triplet":=cpu-verdor-os) is
used to detect so called "host system".

Since this is basic patch, detection of build system in native builds
based on $ac_sys_system and/or $ac_sys_release isn't replaced. This
detection isn't appropriate for cross-compilation environment as contain
values for "build system" and has to be replaces in addition by future
patches.


Also the patch posted in http://bugs.python.org/issue3718 (about
environment variable MACHDEP) isn't required for native builds, but will
help in case of cross-compilation.

The support for *-*mingw* host is enhanced to native msys environment.
This include check for device file /dev/ptmx. The MSYS report that file
exist. As the check is skipped on mingw* host os now cugwin environment
can be used too.

Also check libintl is skipped for mingw as the native build don't use it.

system python has to be at least revision 77704 (trunk)

As part of issue 8510 (update to autoconf2.65) configure script is modernized and most of  updates from patches attached to this issue now are in repository.

Starting from 16 may new patches will include in addition minimal updates of setup.py and Makefile.pre.in (moved from issue 3871) : 
- build modules with system python (from 3871).
- configure ctypes with same arguments as top configure (new)

- consistent platform detection in all methods from setup.py;
- readline libraries detected by configure script are used for setup.py : this could help to detect is more platform independent way if readline is linked with ncurses{w} library;
- ignore "friendly" search library paths : this is useless in case of cross-compilation . Also it is reported that those paths are not so "friendly" even in native builds. Note that with "friendly search library paths" python library search based on file suffix will find libraries system on build system if host system lack them.

Could someone with knowledge of the Python build systems please comment on this, thanks.

It seems to me I forgot to upload version after updates in Lib/sysconfig.py from issue 7880.
I could not understand what Florent Xicluna (flox). I could not reproduce it. To me update abspath -> realpath is bogus and with reverted update of Lib/sysconfig.py test_sysconfig pass.

This patch is restored previous behaviour and now symlinked system python into cross build tree will behave as before i.e. as expected ;)

fixed patch failure on Parser/pgen.stamp

I see some “fix for issue #NNN is bogus” in your patch: would you open separate bug reports for those?  A diff file is not a very useful way to report bugs or express opinions <wink>.

Uhh after some pseudo multiarch improvements previous patch fail. So new one is uploaded.
Also with this version cross-build won't build pgen$(EXEEXT).

Current patch errors with the following message:
gcc -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -L/manual/lib -L/binary/lib -L/manual/lib -L/binary/lib  Parser/acceler.o Parser/grammar1.o Pars
er/listnode.o Parser/node.o Parser/parser.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o
Python/dynamic_annotations.o Python/mysnprintf.o Python/pyctype.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/parsetok_pgen.o Parser/pgenmain
.o -lintl -lpthread  -o Parser/pgen.exe
./Grammar/Grammar ./Include/graminit.h ./Python/graminit.c
./Grammar/Grammar: line 18: single_input:: command not found
./Grammar/Grammar: line 18: simple_stmt: command not found
./Grammar/Grammar: line 18: compound_stmt: command not found
./Grammar/Grammar: line 19: syntax error near unexpected token `NEWLINE'
./Grammar/Grammar: line 19: `file_input: (NEWLINE | stmt)* ENDMARKER'
make: *** [Parser/pgen.stamp] Error 2

Greg, ensure correct configure script first as run commands autoheader and autoconf.
Updates to configure script are not in patch . The patch include updates to source configure.in and autoconf command will update "configure".

Would it be possible to get list of steps required to test this patch?

1. hg clone
2. copy config.sub and config.guess?
3. autoreconf
4. configure...
5. make

What else?

Usually this is not a question for bug-tracking system . configure .. 
--host=.... will enter into cross-compilation mode. You could find more 
details into respective manual.

Roumen

well, looking at the first comment, there is required more than simple read of the manual (i.e. missing config.guess/config.sub).

is anything else missing or required?

as well, by default one experiences

checking for /dev/ptmx... not set
configure: error: set ac_cv_file__dev_ptmx to yes/no in your CONFIG_SITE file when cross compiling


the workaround:

1. create config.site file with the following lines

     ac_cv_file__dev_ptmx=no
     ac_cv_file__dev_ptc=no

2. run configure script as: CONFIG_SITE=config.site ./configure --host...

would be it ok if i add appropriate options for /dev/ptmx and /dev/ptc to this patch so we do not have to play with config.site file?

next question. when starting compilation i am getting

In file included from Include/Python.h:50,
                 from ./Modules/python.c:3:
Include/pyport.h:257:13: error: #error "This platform's pyconfig.h needs to define PY_FORMAT_LONG_LONG"
make: *** [Modules/python.o] Error 1

how to deal with above?

looking into configure.in the above fails due to following check

  AC_MSG_CHECKING(for %lld and %llu printf() format support)

the check compiles and tries to _run_ a bit of software to determine lld/llu support.

that of course fails (we are cross compiling). this is similar problem to ptmx/ptc problem (we do not know if host have support for ptmx/ptc).

i wonder if the following would be acceptable

1. if in cross compilation mode, the configure.in could load config-cross.site.
2. the config-cross.site would define variables for ptmx/ptc, long long format and other checks which consist of running code snippets
3. appropriate checks (i.e. ptmx/ptc, lld/llu) would not be run in cross compilation mode. variables from config-cross.site would be used instead.
4. it would be a developer responsibility to set appropriate values for his platform in config-cross.site file.

does above sound like a solution?

At least one is really would like to cross-compile.

worber, the config site has to look like (sample for linux i?86, i.e. intel 32 bit, as host platform)
=================================
ac_cv_little_endian_double=yes
ac_cv_broken_sem_getvalue=no
ac_cv_computed_gotos=yes
ac_cv_buggy_getaddrinfo=no
ac_cv_working_tzset=yes
#next line require fix typo in configure.in
ac_cv_pthread=yes
ac_cv_pthread_system_supported=yes
ac_cv_tanh_preserves_zero_sign=yes

ac_cv_have_long_long_format=yes
ac_cv_file__dev_ptmx=yes
ac_cv_file__dev_ptc=no
=================================

Also with following patch into configure.in
=======================================
diff --git a/configure.in b/configure.in
--- a/configure.in
+++ b/configure.in
@@ -1372,7 +1372,7 @@
 # so we need to run a program to see whether it really made the
 # function available.
 AC_MSG_CHECKING(whether $CC accepts -pthread)
-AC_CACHE_VAL(ac_cv_thread,
+AC_CACHE_VAL(ac_cv_pthread,
 [ac_save_cc="$CC"
 CC="$CC -pthread"
 AC_RUN_IFELSE([AC_LANG_SOURCE([[
=======================================

Copy-pasting of a previous comment: I see some “fix for issue #NNN is bogus” in your patch: would you open separate bug reports for those?  A diff file is not a very useful way to report bugs or express opinions <wink>.

Copy-pasting of many previous comments: distutils does not get new features (cross-compilation is a new feature), please focus on packaging.