On Mon, Sep 7, 2015 at 1:43 AM, David Ostrovsky <d.ostrov...@gmx.de> wrote:
>
> As you may know there are efforts underway: [1] to support MSVC 14.0.
> After fixing around 20 external libraries and some core places to
> support new compiler, the code can be (more or less) compiled. The tests
> are failing because of EH issue in uno bridge (more on this below).
>
> I have a couple of questions:
>
> * Support UCRT, SDK 10 and .NET 4.6 is quite intrusive change: [2] and
> no wonder, that it's pending for review for months now... nevertheless
> if /me don't see any objections, i will merge this change next week.
Well as long as it does not regress _existing_ platform no problem.
> * Python 3.5 upgrade is needed to support new compiler: [3]. I don't
> have access to Mac OS X atm. Can someone check why Jenkins job on this
> platform is failing: [4]? Moreover new Python release has announced to
> discontinue support for older MS compilers (VS 2013). We never dropped
> support for older compiler during introduction of a new one, right? Or
> would this be a option?
No that is not an option.
having a 'jump over the cliff' commit is just not manageable from a ci
perspective.. not to mention for every other person that currently
build for windows.
We need to have vs 2015 committed and working and then we will migrate
some of the tinderbox, to cover both for a while to avoid bit-rot
and then with enough advance notice to everyone we can consider making
vs2015 a pre-req.
Bearing in mind that this should not be backported to 5.0 or 4.4... so
we will keep vs2013 until at least 5.0 goes out of service.
>Can someone check why Jenkins job on this
platform is failing: [4]?
If fails because python3/Mac/Makefile.in has changed and does not
install pythonw in the framework anymore.
" pythonw is used to run python scripts that may display a graphical
user interface (GUI). Pass the same
arguments to pythonw as you would to python(1). For executable
scripts, use pythonw in the "#!" line.
Actually, since Python 2.5, the normal python also allows GUI
access, so python and pythonw are now
interchangeable.
"
btw that is why the patch names should reflect the version they are
actually patching iow if you need to modify
python-3.3.0-darwin.patch.1 because it does not apply on 3.3.5 it
should really be called pythin-3.3.5-darwin.patch1
anyhow: you need
diff --git a/external/python3/ExternalProject_python3.mk
b/external/python3/ExternalProject_python3.mk
index 29179d5..2f9434d 100644
--- a/external/python3/ExternalProject_python3.mk
+++ b/external/python3/ExternalProject_python3.mk
@@ -139,7 +139,7 @@ $(call
gb_ExternalProject_get_state_target,python3,executables) : $(call
gb_Exte
cd
$(python3_fw_prefix)/Versions/$(PYTHON_VERSION_MAJOR).$(PYTHON_VERSION_MINOR)/bin
; \
for file in python$(PYTHON_VERSION_MAJOR).$(PYTHON_VERSION_MINOR) \
python$(PYTHON_VERSION_MAJOR).$(PYTHON_VERSION_MINOR)m \
-
pythonw$(PYTHON_VERSION_MAJOR).$(PYTHON_VERSION_MINOR) ; do \
+ ; do \
$(INSTALL_NAME_TOOL) -change \
$(python3_fw_prefix)/Versions/$(PYTHON_VERSION_MAJOR).$(PYTHON_VERSION_MINOR)/LibreOfficePython
\
@executable_path/../LibreOfficePython $$file ; done
and, not related to pytonw, but you also need
diff --git a/pyuno/source/module/pyuno.cxx b/pyuno/source/module/pyuno.cxx
index 9e9274ab..7d19b9b 100644
--- a/pyuno/source/module/pyuno.cxx
+++ b/pyuno/source/module/pyuno.cxx
@@ -1610,6 +1610,8 @@ static PyNumberMethods PyUNONumberMethods[] =
nullptr, /*
nb_inplace_true_divide */
nullptr, /* nb_index */
+ nullptr, /* nb_matrix_multiply */
+ nullptr /*
nb_inplace_matrix_multiply */
};
In general when upgrading python you want to keep an eye on
PyNumberMethods and other stuff in
./workdir/UnpackedTarball/python3/Include/object.h
as pyuno depend on it...
Norbert
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
