On 02/18/2016 05:38 PM, Michael Meeks wrote:
* MSVC 14.0 / Drop MSVC 12.0 on master (DavidO)
+ Improvement of C++14/C++17 standard
+ bit rotted on master: dozen compilation errors
+ Add Tinderbox to verify that it still works
+ After release of 5.1 consider to discontinue support for MSVC 12.0 on master
* Looks like it's impossible to manage the switch period
* both compilers could be installed (?) on the same machine, to still use old compiler on
5.1
+ Duplicated Python 3.3/3.5 trees, because upstream dropped support for MSVC 12.0
+ plan was to use Windows Server 2016 + update baseline (Cloph)
+ can setup the tech. preview 4 of Win. Server 2016 & have a t-box.
+ but not convinced on deprecation yet.
+ does 5.0 build with VS 2015 ? (Norbert)
+ No. Requires Python 3.5
Only build on master
+ if so, with the 2x new Windows box showing up
+ install VS 2015 there.
+ then take two others off-line & upgrade them too.
+ even on master - with just VS 2015 - still have issues (Miklos)
+ would be good for now to have a tinderbox to stop it breaking.
+ not fond of multiple versions of compiler (Norbert)
+ can hide problems.
+ concerned we test with only the new compiler (Miklos)
+ new Win boxes physically arrived
+ being moved around at Manitu right now with Alex.
=> put Win Server 2016 Preview 4 + VS 2015
- and bring them on-line and see how it goes.
+ if problems building with 5.0 and 5.1 - re-think.
+ is it confirmed 5.0 builds with VS 2015 ? (Norbert)
+ No. Requires Python 3.5
Only build on master
+ only 1x release left of 5.0.x - anyway (Cloph)
+ to mid April/May.
=> defer update until then.
+ can we somehow restore Thorsten's t-box vs. 2015 ? (Michael)
+ Thorsten's TB was shut down because of devenv.exe invocation
(mst__ has an idea how to fix it?)
+ no idea (mst).
+ migrating slaves of jenkins infra - is a bigger deal - needs a single
toolchain that builds all relevant versions (Norbert).
AI: => will setup a tinderbox VM for VS. 2015 (Cloph)
+ would be good to back-port fixes to 5.1 too to be prepared for May.
What I noticed with my clang-cl build on Windows is that some of the
external modules (at least external/libxmlsec/ExternalProject_xmlsec.mk)
do not get built with whatever is configured as CC/CXX for LO, but
determine that themselves, potentially picking an unexpected MSVC
version if multiple ones are installed?
(It is rather harmless for my clang-cl case, where the main reason to
build with clang-cl is more warnings, which we ignore in external
modules anyway. So it doesn't really matter there that some external
modules are built with MSVC instead of clang-cl. But it might become a
problem for MSVC 2013 vs. 2015 builds, when such an external DLL records
a requirement on the "wrong" compiler runtime DLL.)
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.