Add Windows support#354
Conversation
|
Regarding Incidentally, doing this review would unblock #323 |
|
/ok to test dd1ffc9 |
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
📝 WalkthroughSummary by CodeRabbit
WalkthroughThis PR adds Windows platform support to the nvbench build system and test infrastructure. Changes span CMake configuration, CI scripts, compiler option handling, and test environment setup to conditionally apply Windows-specific behaviors for symbol exporting, library importing, compiler flags, and runtime path resolution. ChangesWindows build and test support
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: ffe8731a-1bea-4fe3-bd00-ae6f639bb863
📒 Files selected for processing (8)
CMakeLists.txtci/build_common.shcmake/NVBenchCUPTI.cmakecmake/NVBenchConfigTarget.cmakenvbench/config.cuh.intesting/axes_metadata.cutesting/cmake/CMakeLists.txttesting/cmake/test_export/CMakeLists.txt
|
I will revert the changes to |
|
@mfranzrebsal The #362 to enable MSVC build of NVBench has been merged, but it is presently unconditionally skipped due to known build failure this PR fixes. Please merge main into this branch, and revert c632eb2 to reenable the PR. The expectation is that CI build using MSVC would complete successfully now. |
mfranzrebsal
force-pushed
the
windows-support
branch
from
edec813 to
787e435
Compare
|
The commit you mention is nowhere to be found, either in main or my rebased branch. I think we are good? |
|
/ok to test 787e435 |
|
@mfranzrebsal Right now the CI has Windows build job disabled in pr.yml#L82-83. Please push a change to remove these two lines to enable the job. |
Remove gate that disables Windows NVBench build job in pr.yaml
|
/ok to test 78b674b |
|
Windows build job fails with: On Linux, the compilation command for This folder should contain "cuda_profiler_api.h" though. |
3 participants
I made the necessary changes for NVBench to build and the tests to pass. I also tested that it works when using NVBench inside of my own project, and made sure that the scripts
ci/build_nvbench.shandci/test_nvbench.shwork. How should support testing be enabled for the CI? I have a local commit with some changes, but did not want to add them here and possibly trip the CI run.Here is a summary of the changes, disclaimer that they were made by Claude and verified by me, but I am in no way a CMake expert:
#: 1
File: CMakeLists.txt
Change: CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON
Failure without it: Link error LNK1181: cannot open input file 'lib\nvbench.lib'. MSVC only generates a .lib import library when the DLL exports symbols. NVBench has no
__declspec(dllexport) annotations, so without this CMake flag, no import library is produced and all downstream targets fail to link.
#: 2
File: cmake/NVBenchCUPTI.cmake
Change: IMPORTED_IMPLIB instead of IMPORTED_LOCATION on Win32
Failure without it: CMake generate error IMPORTED_IMPLIB not set for imported target "nvbench::cupti". On Windows, find_library locates .lib import libraries. A SHARED IMPORTED
target
on Windows requires the .lib path via IMPORTED_IMPLIB (the import library), not IMPORTED_LOCATION (which expects the .dll).
#: 3
File: cmake/NVBenchConfigTarget.cmake
Change: FMT_UNICODE=0, -Xcompiler=/utf-8, --diag_suppress=27
Failure without it: Build errors in every .cu file. (a) fmtlib 11 static-asserts that /utf-8 mode is active — MSVC's host compiler satisfies this with -Xcompiler=/utf-8, but cudafe
evaluates the check independently and always fails, requiring FMT_UNICODE=0 for CUDA. (b) fmtlib's lookup tables use out-of-range char32_t sentinel values that cudafe rejects,
requiring --diag_suppress=27.
#: 4
File: cmake/NVBenchConfigTarget.cmake
Change: AND NOT WIN32 on INSTALL_RPATH
Failure without it: No failure. INSTALL_RPATH is a Unix/ELF concept silently ignored on Windows. The guard is purely a hygiene fix.
#: 5
File: nvbench/config.cuh.in
Change: MSVC_LANG instead of _cplusplus
Failure without it: Build error #error: "NVBench requires a C++17 compiler." in every .cxx file. MSVC reports __cplusplus as 199711L (C++98) regardless of actual standard, unless
/Zc:__cplusplus is passed. _MSVC_LANG always reflects the real standard level.
#: 6
File: testing/axes_metadata.cu
Change: #include
Failure without it: Build error namespace "std" has no member "back_inserter". MSVC's STL doesn't transitively include from like GCC's libstdc++ does.
#: 7
File: testing/cmake/CMakeLists.txt
Change: Forward CMAKE_CUDA_HOST_COMPILER, CMAKE_LINKER, CMAKE_RC_COMPILER, CMAKE_MT
Failure without it: Test failure CUDA_ARCHITECTURES is set to "native", but no NVIDIA GPU was detected. The sub-project cmake configure can't compile/link the GPU query program
#: 8
File: testing/cmake/CMakeLists.txt
Change: ENVIRONMENT "PATH=..." with nvbench bin + CUPTI lib dirs
Failure without it: No failure when run via the build script (which pre-sets PATH). Needed for robustness when ctest is invoked directly — the Windows equivalent of the
LD_LIBRARY_PATH setup the sub-project already has for Unix.
#: 9
File: testing/cmake/test_export/CMakeLists.txt
Change: Add Windows PATH setup for sub-project tests (parallel to existing Unix LD_LIBRARY_PATH)
Reason: The original code only set LD_LIBRARY_PATH on Unix and did nothing on Windows. The sub-project's test_bench.exe and nvbench-ctl.exe need
nvbench.dll and CUPTI DLLs at runtime. On Unix the build tree embeds RUNPATH into the binary so the executable finds libnvbench.so without environment
help; only CUPTI and the install tree need LD_LIBRARY_PATH. Windows has no RUNPATH equivalent — DLL lookup always goes through PATH — so the
sub-project
must set PATH for both tree types. Previously this worked only because the outer test in testing/cmake/CMakeLists.txt set an ENVIRONMENT property on
the ctest --build-and-test process, which the inner CTest happened to inherit. This fix makes the sub-project self-sufficient: it reads the nvbench DLL and CUPTI library locations from imported target properties and sets PATH itself. The shared code resolves the imported configuration once, then
branches only for the CUPTI property name (IMPORTED_IMPLIB on Windows vs IMPORTED_LOCATION on Unix, since find_library locates .lib import libraries on Windows) and the environment variable format.