How do I setup autogen to configure the build of libo-core to use Windows 10 SDK and VS 2017?

I am following the build documentation with the latest master build of v6.x and autogen.sh is displaying the following error:

configure: error: Windows SDK 10 is not known to work with VS 2017

Is there a way to get the tools to display more verbose info to help determine how to fix this?

Does anyone know what may be missing?

I’ve also tried it with VS 2019 and I get the same message.

Here’s my autoreg.input file:

--disable-odk
--with-junit=/cygdrive/c/sources/junit-4.10.jar
--with-ant-home=/cygdrive/c/sources/apache-ant-1.9.5
--enable-pch
--disable-cccache
--with-windows-sdk=10
--with-visual-studio=2017
--enable-64-bit

I’m running autoreg.sh from a Cygwin64 Terminal from a build folder under:

/cygdrive/c/build

And I launch it without parameters (see below) so it uses the above autogen.input file:

/cygdrive/c/sources/libo-core/autogen.sh

Here’s the complete output from autogen.sh:

$ /cygdrive/c/sources/libo-core/autogen.sh
Running ./configure with '--disable-odk --with-junit=/cygdrive/c/sources/junit-4.10.jar --with-ant-home=/cygdrive/c/sources/apache-ant-1.9.5 --enable-pch --disable-ccache --with-windows-sdk=10 --with-visual-studio=2017 --enable-64-bit --enable-option-checking=debug --srcdir=/cygdrive/c/sources/libo-core --enable-option-checking=fatal'
********************************************************************
*
*   Running LibreOffice build configuration.
*
********************************************************************

checking build system type... x86_64-pc-cygwin
checking host system type... x86_64-pc-cygwin
checking for product name... LibreOfficeDev
checking for package version... 6.4.0.0.alpha1+
checking for product version... 6.4
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for grep... (cached) /usr/bin/grep
checking for GNU Make... C:/cygwin64/opt/lo/bin/make
configure: Using a native Win32 GNU Make version.
checking for explicit COMSPEC... found: C:\Windows\system32\cmd.exe
checking for sed... /usr/bin/sed
checking whether to use link-time optimization... no
checking for explicit AFLAGS... no
checking for explicit CFLAGS... no
checking for explicit CXXFLAGS... no
checking for explicit OBJCFLAGS... no
checking for explicit OBJCXXFLAGS... no
checking for explicit LDFLAGS... no
checking whether build target is Release Build... no
checking whether to sign windows build... no
checking for gawk... gawk
checking for gawk... /usr/bin/gawk
checking for bash... /bin/sh
checking for GNU or BSD tar... tar
checking for tar's option to strip components... --strip-components
checking how to build and package galleries... internal src images for desktop
checking whether to build with Java support... yes
checking whether to treat the installation as read-only... no
checking whether to build a 64-bit LibreOffice... yes
checking Visual C++... C:/PROGRA~2/MICROS~1/2017/COMMUN~1/VC
checking for short pathname of VC product directory... C:/PROGRA~2/MICROS~1/2017/COMMUN~1/VC
checking for UCRT location... found
checking for MSBuild.exe location for: 15.0... C:/PROGRA~2/MICROS~1/2017/COMMUN~1/VC/../MSBuild/15.0/Bin/amd64
checking cl.exe... found Visual C++ 2017 (C:/PROGRA~2/MICROS~1/2017/COMMUN~1/VC/Tools/MSVC/1416~1.270/bin/HostX64/x64/cl.exe)
configure: error: Windows SDK 10 is not known to work with VS 2017
Error running configure at /cygdrive/c/sources/libo-core/autogen.sh line 302.

Your question is irrelevant to base (database component of LibreOffice) you used as a tag.

Here’s my autoreg.input file:

I’m running autoreg.sh from a Cygwin64 Terminal from a build folder under:

It’s autogen, not autoreg (details are important, especially when developing, including asking for help in development-related topics, so show others you pay attention to details when preparing questions).

This is a bug in documentation. Running ./autogen.sh --help indeed lists 10 as an acceptable value for --with-windows-sdk; but in fact, 10.0 should be used. Although it is redundant, since by default (when omitted), testing starts with detection of available SDKs in order: 10.0, 8.1(A), 8.0(A). That could be the reason no one had detected this by now :slight_smile:

Thanks for noting; will be fixed in https://gerrit.libreoffice.org/82645; yet note that you should ask development-related questions in #libreoffice-dev @ FreeNode, or in dev mailing list.