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.)
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
