Re: About SCons Re: progress: compiling python2.5 under msys (specifically but not exclusively under wine) with msvcr80

2009-01-23 Thread Roumen Petrov

anatoly techtonik wrote:

On Thu, Jan 22, 2009 at 12:51 AM, Roumen Petrov
 wrote:

Against 2.3, rejected due to dependence on SCons.
Also appears to have been incomplete, needing more work.

No it was complete but use SCons. Most of changes changes in code you will
see again in 3871.



I would better use SCons for both unix and windows builds. In case of
windows for both compilers - mingw and microsoft ones. To port curses
extension to windows I need to know what gcc options mean, what are
the rules to write Makefiles and how to repeat these rules as well as
find options in visual studio interface. Not mentioning various
platform-specific defines and warning fixes.


Did you select one of existing curses library for windows ?

Roumen
--
http://mail.python.org/mailman/listinfo/python-list


Re: progress: compiling python2.5 under msys (specifically but not exclusively under wine) with msvcr80

2009-01-21 Thread Roumen Petrov

Terry Reedy wrote:

Luke Kenneth Casson Leighton wrote:


i look forward to seeing the same incremental improvement applied to
the development of python, evidence of which would be clearly seen by
the acceptance of one of the following patches, one of which is dated
2003:



http://bugs.python.org/issue841454


Against 2.3, rejected due to dependence on SCons.
Also appears to have been incomplete, needing more work.
No it was complete but use SCons. Most of changes changes in code you 
will see again in 3871.



http://bugs.python.org/issue3754


Open by Roumen Petrov, no review, see below.


This is again request and the patch is for trunk. It share common idea with
841454:Cross building python for mingw32:Andreas Ames (yxcv):2003-11-13 
14:31

1006238:Cross compile patch:Daniel Goertzen (goertzen):2004-08-09 22:05
1597850:Cross compiling patches for MINGW hanwen:2006-11-16 16:57



http://bugs.python.org/issue3871


Open, from same submitter, only (minor) review by you.
Does this supercede 3754?
No. It share common changes to code with 841454, 1006238, 1412448, 
1597850. May be 1597850 and 3871 supercede 1412448.


The issue3871 raise questions (and include solution/work around) related to:
2942 - mingw/cygwin do not accept asm file as extension source
2445 - Use The CygwinCCompiler Under Cygwin
1706863 - Failed to build Python 2.5.1 with sqlite3

Also issues related to LDFLAGS:
4010 - configure options don't trickle down to distutils
1628484 - Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

[SNIP]
--
http://mail.python.org/mailman/listinfo/python-list


Re: cross-compilation

2008-08-18 Thread Roumen Petrov

Martin v. Löwis wrote:

What about to start to resolve issues step by step ?


The first step surely should be to get the autoconf issue resolved.

I don't think distutils cross-compilation is going to work, instead,
people wishing to cross-compile should edit Modules/Setup.

Regards,
Martin


Please find attached file "python-2.5.2.patch-CROSS".
Note that this is "proof of concept" unified diff only for configure.in
to show only some changes required for cross-compilation:

- added macro AC_CANONICAL_HOST: this require files config.guess and
 config.sub to be copied to top source directiory. The files can be
obtained from GNU automake distribution. In my test I use files from
automake 1.10.1.

- makefile conditional: the idea is to use in makefiles. It seems to me
that build for PGEN (Parser from Makefile.pre.in) has to be suppress in
case of cross-compilation as example (without related changes):
=
# Parser
@[EMAIL PROTECTED]  Parser/pgen$(EXE)
=

- search for python in build system: usually in the cross environment
we cann't run just build python executable we may use existing
interpreter as example in Makefile.pre.in:
=
@[EMAIL PROTECTED]  [EMAIL PROTECTED]@ @SYSPYTHON@
@[EMAIL PROTECTED]  $(RUNSHARED) ./$(BUILDPYTHON)
=

- $ac_sys_system vs $host: the attached diff show how to detect host
system. The existing detection (variable $ac_sys_system) isn't suitable
for cross-environment.

- ar program : macro AC_CHECK_TOOLS replace AC_CHECK_PROGS. for more
details see autoconf texinfo page.

- detection of files: skip detection in cross-env. and by default assume
   that file don't exists. This is minimal change and I think that we
has to use macro AC_CHECK_FILE and in cross-env. to warn user but this
require more changes.

- creation of files from configure script (note this is not related
directly to cross compilation): the script is changed to use macros
AC_CONFIG_COMMANDS{_PRE}, i.e. more autoconf friendly.


I would like to know what is acceptable for above changes ?
(note that changes for mingw are only to show idea how to get host
system and i will exclude from final patch ).


Also how to proceed ?
Must I open new issue and to mark that as example 1597850 depend from
new one ?
What is preferred patch: against trunk, release2.5 or both ?


Roumen


--- ./configure.in.CROSS2008-02-13 21:17:17.0 +0200
+++ ./configure.in  2008-08-19 03:11:48.0 +0300
@@ -8,6 +8,7 @@
 AC_INIT(python, PYTHON_VERSION, http://www.python.org/python-bugs)
 AC_CONFIG_SRCDIR([Include/object.h])
 AC_CONFIG_HEADER(pyconfig.h)
+AC_CANONICAL_HOST
 
 dnl This is for stuff that absolutely must end up in pyconfig.h.
 dnl Please use pyport.h instead, if possible.
@@ -30,6 +31,36 @@
 rm confdefs.h
 mv confdefs.h.new confdefs.h
 
+dnl makefile conditional (for future use)
+if test "x$cross_compiling" = xyes; then
+  CROSS_ON=''
+  CROSS_OFF='#'
+else
+  CROSS_ON='#'
+  CROSS_OFF=''
+fi
+AC_SUBST(CROSS_ON)
+AC_SUBST(CROSS_OFF)
+
+if test "x$cross_compiling" = xyes; then
+  AC_MSG_NOTICE([cross-compilation is incomplete])
+
+  dnl in cross-compilation environment we need python from
+  dnl build system (for future use)
+  AC_PATH_PROG(SYSPYTHON, python, [none],
+[$PATH:/usr/local/bin]
+  )
+  if test "x$PYTHON" = xnone; then
+AC_MSG_ERROR([python program is required in cross-compilation environment])
+  fi
+
+  dnl HOST_OS is a variable to be used in makefiles to inform other
+  dnl tools for real host system if differ from build system
+  dnl (reserved for future use)
+  HOST_OS=$host_os
+fi
+AC_SUBST(HOST_OS)
+
 AC_SUBST(VERSION)
 VERSION=PYTHON_VERSION
 
@@ -585,6 +616,10 @@
   *)
 enable_shared="no";;
   esac
+  case $host in
+  *-*-mingw*)
+enable_shared="yes";;
+  esac
 fi
 AC_MSG_RESULT($enable_shared)
 
@@ -593,11 +628,11 @@
   AC_HELP_STRING(--enable-profiling, enable C-level code 
profiling),
 [ac_save_cc="$CC"
  CC="$CC -pg"
- AC_TRY_RUN([int main() { return 0; }],
+ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([],[[int main() { return 0; }]])],
ac_enable_profiling="yes",
-   ac_enable_profiling="no",
ac_enable_profiling="no")
- CC="$ac_save_cc"])
+ CC="$ac_save_cc"],
+   ac_enable_profiling="no")
 AC_MSG_RESULT($ac_enable_profiling)
 
 case "$ac_enable_profiling" in
@@ -675,6 +710,13 @@
  
RUNSHARED=DLL_PATH=`pwd`:${DLL_PATH:-/atheos/sys/libs:/atheos/autolnk/lib}
  ;;
   esac
+  case $host in
+*-*-mingw*)
+  LDLIBRARY='libpython$(VERSION).dll.a'
+  DLLLIBRARY='libpython$(VERSION).dll'
+  BLDLIBRARY='-L. -lpython$(VERSION)'
+  ;;
+  esac
 else # shared is disabled
   case $ac_sys_system in
 CYGWIN*)
@@ -682,13 +724,16 @@
   LDLIBRARY='libpython$(VERSION).dll.a'
   ;;
   esac
+  case $host in
+*-*-mingw*)
+  LDLIBRARY='libpython$(VERSION).dll.a';;
+  esac
 fi
 
 AC_MSG_RESULT($LDLIBRARY)
 
 AC_PROG_RANLIB
-AC_SUBST(AR)
-AC_CHECK_PROGS(AR, 

cross-compilation

2008-08-06 Thread Roumen Petrov

Hi list members,

It seems to me that this is discussed many times in the past but without 
 progress. As I understand in general there is no objections and 
preferred cross-compilation has to be based on distutils (scons was 
rejected).


So I would like to cross-compile from linux(build system) to the 
mingw(host system) and note some(many) problems:


- the configure script don't support cross-compilation:
  The first is lack of macro AC_CANONICAL_HOST.
  Next is AC_TRY_RUN with two arguments.

- native mingw build isn't supported well:
  As example updated ifdefs from issue 1412448 aren't in the code. The 
posixmodule.c is required and I expect native build to fail. May be same 
for pwdmodule.c.


- the build process may require python installed on build system and the 
"distutils" may be isn't aware that cross-compilation is requested. In 
general isn't possible to run on build platform executable just build 
for host platform. Linux plus emulator is an exception.


What about to start to resolve issues step by step ?

Roumen
--
http://mail.python.org/mailman/listinfo/python-list