[x265] [PATCH] cmake: specify default Windows target O/S as Win7, to enable NUMA APIs

[Steve Borho]

# HG changeset patch
# User Steve Borho <steve at borho.org>
# Date 1428844510 18000
#      Sun Apr 12 08:15:10 2015 -0500
# Node ID 34fa761d51bb8deeef79b94660ca723e441cf34c
# Parent  2884fb7795783609114674ff498d9f2e30fb7235
cmake: specify default Windows target O/S as Win7, to enable NUMA APIs

after this change, our builds will target Windows 7 and later operating systems
by default, unless the WINXP_SUPPORT option is enabled. The NUMA APIs that we
need to give processor affinity to pool threads were introduced in Windows 7.
XP and Vista get lumped together into one *legacy* build option.

diff -r 2884fb779578 -r 34fa761d51bb doc/reST/cli.rst
--- a/doc/reST/cli.rst	Thu Apr 09 15:24:17 2015 +0530
+++ b/doc/reST/cli.rst	Sun Apr 12 08:15:10 2015 -0500
@@ -219,7 +219,8 @@
 
 	On Windows, the native APIs offer sufficient functionality to
 	discover the NUMA topology and enforce the thread affinity that
-	libx265 needs, but on POSIX systems it relies on libnuma for this
+	libx265 needs (so long as you have not chosen to target XP or
+	Vista), but on POSIX systems it relies on libnuma for this
 	functionality. If your target POSIX system is single socket, then
 	building without libnuma is a perfectly reasonable option, as it
 	will have no effect on the runtime behavior. On a multiple-socket
diff -r 2884fb779578 -r 34fa761d51bb doc/reST/threading.rst
--- a/doc/reST/threading.rst	Thu Apr 09 15:24:17 2015 +0530
+++ b/doc/reST/threading.rst	Sun Apr 12 08:15:10 2015 -0500
@@ -34,15 +34,16 @@
 and find more work.
 
 On Windows, the native APIs offer sufficient functionality to discover
-the NUMA topology and enforce the thread affinity that libx265 needs,
-but on POSIX systems it relies on libnuma for this functionality. If
-your target POSIX system is single socket, then building without libnuma
-is a perfectly reasonable option, as it will have no effect on the
-runtime behavior. On a multiple-socket system, a POSIX build of libx265
-without libnuma will be less work efficient, but will still function
-correctly. You lose the work isolation effect that keeps each frame
-encoder from only using the threads of a single socket and so you incur
-a heavier context switching cost.
+the NUMA topology and enforce the thread affinity that libx265 needs (so
+long as you have not chosen to target XP or Vista), but on POSIX systems
+it relies on libnuma for this functionality. If your target POSIX system
+is single socket, then building without libnuma is a perfectly
+reasonable option, as it will have no effect on the runtime behavior. On
+a multiple-socket system, a POSIX build of libx265 without libnuma will
+be less work efficient, but will still function correctly. You lose the
+work isolation effect that keeps each frame encoder from only using the
+threads of a single socket and so you incur a heavier context switching
+cost.
 
 Wavefront Parallel Processing
 =============================
diff -r 2884fb779578 -r 34fa761d51bb source/CMakeLists.txt
--- a/source/CMakeLists.txt	Thu Apr 09 15:24:17 2015 +0530
+++ b/source/CMakeLists.txt	Sun Apr 12 08:15:10 2015 -0500
@@ -301,12 +301,15 @@
         list(APPEND PLATFORM_LIBS ${VLD_LIBRARIES})
         link_directories(${VLD_LIBRARY_DIRS})
     endif()
-    option(WINXP_SUPPORT "Make binaries compatible with Windows XP" OFF)
+    option(WINXP_SUPPORT "Make binaries compatible with Windows XP and Vista" OFF)
     if(WINXP_SUPPORT)
         # force use of workarounds for CONDITION_VARIABLE and atomic
         # intrinsics introduced after XP
         add_definitions(-D_WIN32_WINNT=_WIN32_WINNT_WINXP)
-    endif()
+    else(WINXP_SUPPORT)
+        # default to targeting Windows 7 for the NUMA APIs
+        add_definitions(-D_WIN32_WINNT=_WIN32_WINNT_WIN7)
+    endif(WINXP_SUPPORT)
 endif()
 
 include(version) # determine X265_VERSION and X265_LATEST_TAG