I have recently removed from oowintool two checks that were looking for a particular versions of SDK. The reason was that 1) if the SDK is not registered with visual studio, our vsbuild.exe built external libraries have problem and 2) The 6.1 that oowintool was looking for has the habit to leave lingering registry keys even after being uninstalled, so it is creating a mighty mess when the registry key points to something that is actually not there.
oowintool looks now for the default SDK and if it does not find it, it will fail. Better at the configure time then later in the build with cryptic errors. Cheers Fridrich On 26/03/12 23:52, Lubos Lunak wrote: > On Monday 26 of March 2012, Kohei Yoshida wrote: >> On Mon, Mar 26, 2012 at 5:14 PM, Regina Henschel >> >> <rb.hensc...@t-online.de> wrote: >>>>> I have tried also with >>>>> --with-windows-sdk-home="/cygdrive/c/Programme/Microsoft >>>>> SDKs/Windows/v6.0A" >>>> >>>> I believe that configure option has been renamed to >>>> --with-dotnet-framework-home. E.g. I have >>>> >>>> --with-dotnet-framework-home="/cygdrive/c/Program Files/Microsoft >>>> SDKs/Windows/v7.0A" >>>> >>>> in my configure option. >>> >>> No, that does not solve the problem, neither with >>> --with-dotnet-framework-home alone nor in combination with >>> --with-windows-sdk-home >> >> Hmm.. Anyone else have any ideas? > > I think one thing that has changed relatively recently is that the SDK must > be registered as default with Visual Studio (in the menu: Microsoft Windows > SDK 7.1 -> Visual Studio Registration -> Windows SDK Configuration Tool). > > You can also have a look at configure.in to see what the check actually > looks > for. > _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice