Just for Information: Support for VS 2019 Preview 1

himajin100000 himajin100000 at gmail.com
Thu Dec 13 02:25:31 UTC 2018


In addtion to the modification given in
https://gerrit.libreoffice.org/#/c/64630/

I needed to:

1.
https://opengrok.libreoffice.org/xref/core/external/twain_dsm/ExternalProject_twain_dsm.mk?r=585d9806#26

I need to consider $(VCVER) = 160 and $(VCVER)-$(WINDOWS_SDK_VERSION) = 
160-10 case for all the similar cases:

https://opengrok.libreoffice.org/search?project=core&q=VCVER&defs=&refs=&path=&hist=&type=

$(if $(filter 160,$(VCVER)),/p:PlatformToolset=v141 
/p:VisualStudioVersion=16.0 /ToolsVersion:Current) \

$(if $(filter 
160-10,$(VCVER)-$(WINDOWS_SDK_VERSION)),/p:WindowsTargetPlatformVersion=$(UCRTVERSION)) 
\

2.
https://opengrok.libreoffice.org/xref/core/configure.ac?r=905c107c#3432
I don't have 16.0 folder under MSBuild directory.
What I have is "Current" directory. so I need special treatment for this 
case.

but even when configure failed to find the MSBuild.exe based on this 
rule, if another MSBuild is found in one of the PATHs added during build 
process, the build process might succeed. This case seemed to happen to 
me somehow only for x64(probably from old .NET stuffs). For x86,error 
for unsupported ToolsVersion was given. weird.

3. regarding lcms2,

https://opengrok.libreoffice.org/xref/core/external/lcms2/ExternalProject_lcms2.mk?r=e751e242#26

currently, the code rebased to master has 2015 directory under Projects 
folder, and code on github has 2017 directory

https://github.com/mm2/Little-CMS/tree/master/Projects/VC2017

for now, I changed the directory from 2013 to 2015, and can successfully 
build the source. Would it be better to update the archive on 
libreoffice to rebase to the one in github and change the diretory to 
2017? If yes, how can I ask the server manager to add the updated archive?

https://opengrok.libreoffice.org/xref/core/download.lst?r=a01ac385#140

4. regarding python3,
"Project not selected to build for this solution" error is given for 
xxlimit and _freeze_importlib

the cause seemed that though pcbuild.sln assigned 
{F749B822-B489-4CA5-A3AD-CE078F5F338A} for the xxlimit project, the only 
configurations existed were

{F749B822-B489-4CA5-A3AD-CE078F5F338A}.Debug|Win32.ActiveCfg = Debug|Win32
{F749B822-B489-4CA5-A3AD-CE078F5F338A}.Debug|x64.ActiveCfg = Debug|x64

and I needed the configurations for Build.0

{F749B822-B489-4CA5-A3AD-CE078F5F338A}.Debug|Win32.Build.0 = Debug|Win32		
{F749B822-B489-4CA5-A3AD-CE078F5F338A}.Debug|x64.Build.0 = Debug|x64

And the same for the _freeze_importlib.

5.
pyproject.props in XML format stores the data for the file to be 
produced for each project in python. This data contains newlines and is 
stored in attributes. but newlines in attributes are often changed to a 
single white space. therefore

#define FIELD3 5150
#define MS_DLL_ID "3.5-32"
#define PYTHON_DLL_NAME "_ctypes_d.pyd"

becomes

#define FIELD3 5150 #define MS_DLL_ID "3.5-32" #define PYTHON_DLL_NAME 
"_ctypes_d.pyd"

in pythonnt_rc.h files in each _ctypes project. Almost the 
same(PYTHON_DLL_NAME needs to be adapted) for other projects.

6.
For the same reason given in the No.5,

some projects have

setlocal
set PYTHONPATH=$(PySourcePath)Lib
"$(OutDir)python$(PyDebugExt).exe"
"$(PySourcePath)PC\validate_ucrtbase.py" $(UcrtName)'

stored in attributes, resuting in

setlocal set PYTHONPATH=$(PySourcePath)Lib

so, I mean to change to

setlocal && set PYTHONPATH=$(PySourcePath)Lib

for XML, I did

setlocal && set PYTHONPATH=$(PySourcePath)Lib

I forgot exact what projects are in this symptom

7.
xxlimited.vcxproj has Py_LIMITED_API=0x03050000 but this is incompatible 
with debug build. I removed that.


More information about the LibreOffice mailing list