Date: prev next · Thread: first prev next last
2018 Archives by date, by thread · List index


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.

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.