feat(simplemath): port SimpleMath to DirectXMath

[RohithPariki]

Problem

Users want to consume SimpleMath — the simplified C++ math wrapper for DirectXMath — without taking a dependency on the entire DirectX Tool Kit.
See #327.

Root Cause

SimpleMath lives in DirectXTK because it was originally designed as part of an XNA-parity layer. However, the three files that make up SimpleMath (SimpleMath.h, SimpleMath.inl, SimpleMath.cpp) only depend on DirectXMath.h, DirectXPackedVector.h, and DirectXCollision.h — all headers already present in this repository.

Solution

This PR directly follows the approach outlined by Chuck Walbourn (@walbourn) in #327:

"it would be like the SHMath module it would need a sub cmake"
"the library files are MIT and could easily be copied into any project … you'd need a pch.h for it to find or to edit the .cpp"

The implementation mirrors the existing SHMath pattern exactly:

• Adds a SimpleMath/ subdirectory containing SimpleMath.h, SimpleMath.inl, and SimpleMath.cpp.
• Adds a dedicated SimpleMath/CMakeLists.txt modelled on SHMath/CMakeLists.txt.
• Sets SIMPLEMATH_VERSION to 1.0.0 as this is its first introduction into the DirectXMath tree.
• Adds a BUILD_SIMPLEMATH option to the root CMakeLists.txt, disabled by default, consistent with the existing BUILD_SHMATH / BUILD_XDSP pattern.
• Removes #include "pch.h" from SimpleMath.cpp to make it standalone (the "edit the .cpp" approach referenced in the issue).
• SimpleMath.inl is listed in LIBRARY_HEADERS so it is installed alongside the header on make install.
• Removed the sal.h download block and SSE2 architecture detection that were present in the SHMath template, as SimpleMath.cpp only defines static constants and contains no SIMD intrinsics or SAL annotations.
• DIRECTX_TOOLKIT_API export macro is preserved as-is; it defaults to an empty definition in a static library build when neither DIRECTX_TOOLKIT_EXPORT nor DIRECTX_TOOLKIT_IMPORT is defined.

Testing

Compiled SimpleMath.cpp against the DirectXMath headers in this repository using GCC 6.3.0 (MinGW) with _XM_NO_INTRINSICS_ and the existing Tests/sal.h stub (same approach used by the repo's own local tests). Compilation exits cleanly with zero errors. All warnings are deprecation notices in DirectXPackedVector.h pre-existing in the DirectXMath headers themselves — none originate from SimpleMath.

g++ -std=c++17 -D_XM_NO_INTRINSICS_ -IInc -ISimpleMath -ITests -c SimpleMath/SimpleMath.cpp
# exit 0

Full MSVC + Windows SDK build would exercise the dxgi1_2.h path (guarded by #ifdef _WIN32) which is outside the scope of this local toolchain.

Risk

Low — this is a purely opt-in addition behind BUILD_SIMPLEMATH, which defaults to OFF. No existing code paths are altered. The DIRECTX_TOOLKIT_API macro is not renamed, preserving ABI compatibility for any user migrating between the standalone and DirectXTK builds.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Chuck Walbourn (walbourn)]

It probably makes most sense here to mirror DirectX Tool Kit so that if you are using VCPKG to consume these things, they are consistent.

option(BUILD_SHARED_LIBS "Build SimpleMath as a shared library" OFF)

add_library(${PROJECT_NAME})

target_sources(${PROJECT_NAME} PRIVATE ${LIBRARY_HEADERS} ${LIBRARY_SOURCES})

if(WIN32 AND BUILD_SHARED_LIBS)
  message(STATUS "Build SimpleMath library as a DLL")

  configure_file(
      "${CMAKE_CURRENT_SOURCE_DIR}/build/SimpleMath.rc.in"
      "${CMAKE_CURRENT_BINARY_DIR}/SimpleMath.rc" @ONLY)

  target_sources(${PROJECT_NAME} PRIVATE "${CMAKE_CURRENT_BINARY_DIR}/SimpleMath.rc")

  target_compile_definitions(${PROJECT_NAME} PRIVATE DIRECTX_TOOLKIT_EXPORT)
  target_compile_definitions(${PROJECT_NAME} INTERFACE DIRECTX_TOOLKIT_IMPORT)
endif()

[Chuck Walbourn (walbourn)]

It made sense to me to keep this 'inline' when only SHMath needed these switches. If we are moving to a case where two CMakeLists.txt use it, then we should create a build folder with CompilerAndLinker.cmake and have both CMakes use it via an include.

This might also require refactoring the CMakes to only let 'top-level' build as with my other projects and then update any test YAML pipline that uses the SMath\CMakeLists.txt directly.

[Chuck Walbourn (walbourn)]

You will need a build folder anyhow for SimpleMath.rc.in above.

[RohithPariki]

Hi Chuck Walbourn (@walbourn) sir, thanks for the review. I've addressed the requested changes:

• Refactored the compiler/linker configuration into build/CompilerAndLinker.cmake, using aggregated COMPILER_DEFINES, COMPILER_SWITCHES, and LINKER_SWITCHES, with both SHMath and SimpleMath applying them after target creation.
• Updated SimpleMath's CMake configuration to mirror DirectX Tool Kit's static/shared library handling, including the Windows DLL resource/export/import configuration.
• Added BUILD_SIMPLEMATH=ON to the existing SHMath CI configuration so the new CMake target is exercised across the build matrix.
• Verified the install/consumer flow, including a Windows shared-library build and a fresh find_package(SimpleMath CONFIG REQUIRED) consumer linking against Microsoft::SimpleMath.

Could you please take another look when you get time for this , so that i can work on further changes.