Re: [PATCH] pyuno is broken on mingw on current master

Hi,

On Mon, Jun 18, 2012 at 01:15:05AM +0200, David Ostrovsky wrote:
> On 12.06.2012 09:23, Stephan Bergmann wrote:
> > On 06/12/2012 09:17 AM, David Ostrovsky wrote:
> > > What do you mean here?
> >
> > Personally, for an experimental platform like mingw, and as you
> > have demonstrated that it does not work right now, I would not
> > bother to make it work prior to gbuild'ification.
> >
> > Has pyuno on mingw ever been known to work?
> yes ... with attached patch ;-)

Nice :-)

> (actually only python.exe with import pyuno was working, open macro
> dialog from swriter is still crashing, but I suspect some other
> problems here, need to look into it)
>
> Actually we have two routes to go here:
> 1/ Taking system-python into installation set (this combination is
> unique: no other platform using it, but normal on mingw, see
> external/mingw-dlls/makefile.mk)
> 2/ Having internal python compiles on mingw and packaging it like on
> other platforms. I've seen that David Tardon is working on it.

That was just a feeble attempt... I do not suppose I will continue,
because I am not actually very interested in it. And if/when we start to
use MinGW as the platform for producing Windows builds, the build system
is most probably going to be SuSE, where mingw32-python is available, so
the --with-python=system route is more promising anyway.

> I'm taking the first route with this patch (but i tried to take into
> consideration that internal python may be working some day on mingw,
> that why more if else endif as needed in pyuno module)
>
> ** new MINGW_PYTHON specific vars are exported in configure.in:
> grep -i -e mingw_py -e mingw_readline -e mingw_termcap config_host.mk
> export MINGW_PYTHON_DLL=libpython2.6.dll
> export MINGW_PYTHON_MAJOR_VERSION=2.6

Nitpick: this is really MAJOR_VERSION.MINOR_VERSION .

> export MINGW_PYVERSION=2.6.2
> export MINGW_PYTHON_SYSROOT=/usr/i686-w64-mingw32/sys-root/mingw

This variable should not be python specific. The sys-root is already
hardcoded at several places--in configure.in, m4/mingw.m4,
external/mingw-dlls/makefile.mk..., so it is time to introduce a
variable for it.

> export MINGW_READLINE_DLL=libreadline6.dll
> export MINGW_TERMCAP_DLL=libtermcap-0.dll
>
> ** python_wrapper.exe has to be built (with pyversion.hxx and
> delivering). Changed from python.bin to python.exe in python.cxx.

Why? I think it may cause confusion, if there are two python.exe
binaries, in different dirs. Moreover, make_installer.pl cannot handle
it. (the configuration in scp2 describes how the installation will look
like, not where the files are to be found. That is handled by another
configuration file--instsetoo_native/util/openoffice.lst--which sets
include path, where make_installer.pl will look for files).

> ** external/mingw-dlls: libpython2.6.dll and two other depended libs
> are copied(readline & termcap)
>
> Can this part be optimized? copying for now
> /usr/i686-w64-mingw32/sys-root/mingw/bin/python.exe to
> (OUTDIR)/bin/python.exe
> with new makefile CustomTarget_python_mingw_bin.mk and wonder if it
> can be done directly in scp2 (without using
> CustomTarget_python_mingw_bin.mk):
> define something like that:
>     -DMINGW_SYSTEM_PYTHON_BIN_DIR=$(MINGW_PYTHON_SYSROOT)/bin \
> and try to use it in Dir/File rule?

No, it cannot. I think we could dispose of the copying (including the
dlls) by adding the mingw sysroot into include path for installer, which
should be a simple change in instsetoo_native/util/openoffice.lst and
solenv/bin/modules/installer/worker.pm .

> May be i did too much copy/paste here? Is it really needed to
> differentiate between SYSTEM_PYTHON=NO and MINGW_SYSTEM_PYTHON =
> YES?

I am afraid I do not even understand the question :-)

> Can it be done with simple OR-operator (i.e. combine these cases somehow=?
>
> o python.exe (wrapper) is copied from (OUTDIR)/bin/pyuno/python.exe
> to program/python.exe
>
> Thanks
> David
>
> PS: packaging part is still need to be tested.

> diff --git a/configure.in b/configure.in
> index 011aa22..8faca38 100644
> --- a/configure.in
> +++ b/configure.in
> @@ -6678,12 +6678,23 @@ if test $enable_python = system; then
>      else
>          dnl How to find out the cross-compilation Python installation path?
>          dnl Let's hardocode what we know for different distributions for now...
> -
>          for python_sysroot in /usr/i686-w64-mingw32/sys-root/mingw; do
>              for python_version in 2.6; do
>                  if test -f ${python_sysroot}/include/python${python_version}/Python.h; then
> +                    MINGW_PYTHON_SYSROOT=$python_sysroot
>                      PYTHON_CFLAGS="-I${python_sysroot}/include/python$python_version"
>                      PYTHON_LIBS="-L${python_sysroot}lib -lpython$python_version $python_libs"
> +                    libo_MINGW_CHECK_DLL([PYTHON], [libpython$python_version])
> +                    # suffix 6 is hard coded?
> +                    libo_MINGW_CHECK_DLL([READLINE], [libreadline6])
> +                    # suffix -0 is hard coded?
> +                    libo_MINGW_CHECK_DLL([TERMCAP], [libtermcap-0])

libo_MINGW_CHECK_DLL([TERMCAP], [libtermcap]) is sufficient. The macro
is smart enough to find the version suffix. (Not in the case of
libreadline6, because the version is part of the library name there.)

> diff --git a/pyuno/CustomTarget_python_mingw_bin.mk b/pyuno/CustomTarget_python_mingw_bin.mk
> new file mode 100644
> index 0000000..d6ccabe
> --- /dev/null
> +++ b/pyuno/CustomTarget_python_mingw_bin.mk
> +$(eval $(call gb_CustomTarget_CustomTarget,pyuno/python_mingw_bin))
> +
> +python_mingw_bin_SOURCE := $(MINGW_PYTHON_SYSROOT)/bin/python.exe
> +python_mingw_bin_TARGET := $(OUTDIR)/bin/python.exe
> +
> +$(call gb_CustomTarget_get_target,pyuno/python_mingw_bin) : $(python_mingw_bin_TARGET)
> +
> +$(python_mingw_bin_TARGET) : $(python_mingw_bin_SOURCE)
> +     cp $< $@

I suggest to move this to external/mingw-dlls/makefile.mk . IMHO it does
not make much sense to do this as a special case.

> diff --git a/scp2/source/python/file_python.scp b/scp2/source/python/file_python.scp
> index 47ab5fe..b761620 100644
> --- a/scp2/source/python/file_python.scp
> +++ b/scp2/source/python/file_python.scp
>  
> +#ifdef MINGW_SYSTEM_PYTHON
> +
> +// python_wrapper.exe
> +File gid_File_Py_Bin_Python
> +    BIN_FILE_BODY;
> +    Name = EXENAME(pyuno/python);

I think this will not work. And even if it would, it feels like a hack,
because this clause defines a file, so there should be no path. There
should be a definition for pyuno dir too and the file should be added to
it.

D.