* Windows XP SP2 is 0x0502, see
http://msdn.microsoft.com/en-us/library/aa383745.aspx
* If a module changes the Windows SDK version setting,
this is done module wide now. So the overall behavior
is as before. This seems to be the best compromise for
now.
* We need at least SP2 because of the bluetooth stuff
used in sd/source/ui/remotecontrol.
* Now, we require at least Internet Explorer 7.0. IE6
has been outdated for a long time.
* Leave StdAfx.h file definitions, as those are Microsoft
project specific precompiled header files.
* All local definitions of WINVER are removed, because
the global WINVER setting makes them obsolete now.
To the relation of the three macros:
Setting _WIN32_WINNT sets WINVER and NTDDI_VERSION
automatically to the same value as _WIN32_WINNT.
WINVER and NTDDI_VERSION can be set idenpendently each
for itself.
Change-Id: Ibcc12493aae4fcaf7bcfda88be99c1b61bc326cb
Reviewed-on: https://gerrit.libreoffice.org/6496
Reviewed-by: Thorsten Behrens <thb@documentfoundation.org>
Tested-by: Thorsten Behrens <thb@documentfoundation.org>
* Re-use existing settings/dk.mk to tunnel ENABLE_DEBUG into the SDK. Turns out
this was explicitly included in ~all examples Makefiles, but only after
settings.mk where it is now used, so include it in settings.mk now and dropped
it from all the exmaples Makefiles.
* The old settings.mk was apparently confused with using /MT ("link with
LIBCMT.LIB") on cl command line and /MD ("link with MSVCRT.LIB") on link
command line (where it was ignored), and you apparently can't pass both
together to cl, so I settled on /MD (resp. /MDd) now and dropped /MT (resp.
/MTd). No idea if that is exactly right, however.
* Introduced client-facing LIBO_SDK_LDFLAGS_STDLIBS that covers kernel32.lib and
msvcrt.lib vs. msvcrtd.lib on Windows. Adapted examples Makefiles and
/ure/source/uretest/Makefile accordingly. Some examples Makefiles
additionally use msvcprt.lib, no idea whether that still needs to be
addressed.
Change-Id: Ia8d9d177e415abfbaf6f9fa6239f0ef9998868be
Evidently on Windows, the newfangled ucpp handles #include "foo"
differently from #include <foo> and treats it as a relative path, while
the angle brackets always result in absolute paths.
Since relative paths result in infinite rebuilds if make is invoked in a
different directory, don't use #include "foo" in IDL files.
Change-Id: Iedcda3a4be5542389a0be086f14541cda8dc5323