Re: Efforts to support MSVC 14.0
On Mon, Sep 7, 2015 at 1:43 AM, David Ostrovsky 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
Re: Efforts to support MSVC 14.0
On Mon, Sep 7, 2015 at 2:43 AM, David Ostrovsky wrote: > > * EH issue in uno_bridge: to compute the offset in _tiddata structure > for _curexception and _tpxcptinfoptrs members, I've written this > utility: [6] during work on support for 64 bit platform. Unfortunately, > this code can't be compiled on MSVC 14.0, as mtdll.h isn't there any > more (or I haven't found it). > Seems mtdll.h is internal and hence unsupported. _tiddata might have been moved to a new header. If it's nowhere to be found, _tiddata struct could be replicated directly in the compute_exception_offset source code and remove that header altogether (assuming it hasn't changed). Of course all this is already having an arm and a leg in the guts of the runtime and is therefore fragile (I assume there was no better way). Would be good if there were an automatic sanity test in that code to detect any changes between compiler versions/patches/updates that might otherwise go unnoticed. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Efforts to support MSVC 14.0
On 07.09.2015 08:43, David Ostrovsky wrote: > * 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? as Norbert already said, a "flag day" to require new compiler is not an option. unfortunately CPython 3.5 has removed the project files for older MSVC versions. (btw, there is an RC3 already now) this leaves several bad options to deal with the transition: 1. bundle 2 different pythons depending on MSVC version (eek!) these would have different sets of patches, and the build system would probably need to check PYTHON_VERSION_MINOR in some places to do different things. 2. patch in the old PCbuild dir from a previous release as PC/VS10.0 dir (eek!) it looks like that was removed with the following changeset: changeset: 93858:5754f069b123 user:Steve Dower date:Sat Nov 22 12:54:57 2014 -0800 summary: Issue #22919: Windows build updated to support VC 14.0 (Visual Studio 2015), which will be used for the official 3.5 release. no idea how much work that would be and how many refactorings that happened upstream since November aren't reflected in the deleted project files. 3. always --disable-python for now on MSVC2015 builds we can switch at a later point, when we switch the release builds to MSVC 2015 (and then enforce --disable-python for MSVC2013). or do it temporarily until we decide to do 1. or 2. :) of course nothing prevents having the patch in gerrit to upgrade to python 3.5 for those using MSVC2015. so which option is the least bad? hard to predict which of 1. or 2. would be more work. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Efforts to support MSVC 14.0
On Mon, 2015-09-07 at 08:11 -0500, Norbert Thiebaud wrote: > On Mon, Sep 7, 2015 at 1:43 AM, David Ostrovsky 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. Actually after comment from Michael Stahl. I've rewritten this change from scratch. Now it's smaller and should be easier to review. > > > * 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. OK, so we've moved old external/python3 directory to python33. This location is only used with old (default VS 2013) compiler. > >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. Thanks. Fixed. There is one problem with MSI, merge module. During the installation, runtime DLLs are installed in wrong directory: [1]. Workaround is to install redist package manually: [2]. Next steps: * merge pending changes in gerrit: [3] * set up Tinderbox with new compiler and upload binary artifacts * ask QA folks to test * migrate other tinderboxes to use the new compiler * rise compiler baseline and discontinue support for VS 2013 * drop old python33 directory * [1] https://connect.microsoft.com/VisualStudio/feedback/details/1746644/microsoft-vc140-crt-x64-msm-merge-module-installs-c-c-runtime-dlls-in-x32-folder * [2] https://www.microsoft.com/en-us/download/details.aspx?id=48145 * [3] https://gerrit.libreoffice.org/#/q/status:open+project:core +branch:master+topic:vs-2015 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
