Apply CMake best practices and remove stale references#1416
Conversation
34e4948 to
790fdd0
Compare
9a5a166 to
2feeb94
Compare
Copilot review on PR microsoft#1416 flagged that mapping VisualStudioVersion >= 18.0 to PlatformToolset v145 is a guess: VS 2025/2026/etc. has not shipped, the toolset moniker for that release may differ, and pinning to a non-existent toolset name causes MSBuild to fail early with "unknown PlatformToolset" on any machine that does pick up that VS version. Drop the v145 mapping from both before.targets and build.MIP.props. Future VS versions fall through to the v141 fallback (same behavior as before PR microsoft#1416, just one less wrong-toolset-name failure mode). Add explicit mappings for new toolsets as they actually ship. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Addressed Copilot round 2: dropped the speculative |
The top-level CMakeLists.txt asks for C++14 (CMAKE_CXX_STANDARD 14, set in 2018) but then re-injects -std=c++11 into CMAKE_CXX_FLAGS for both Release and Debug Unix builds (set in 2019 when gcc-4.x / gcc-5.x C++14 support was still spotty). That explicit flag wins, so the Unix builds have actually been C++11 ever since, contradicting the stated standard. This is a vestige: gcc-5+, clang-3.4+, and MSVC 2015+ all support C++14 fully, and Android (lib/android_build/) already sets CMAKE_CXX_STANDARD 14 explicitly. Removing the override aligns the Unix CMake builds with the intended standard. - Drop the stale gcc-4.x/5.x caveat comment and add CMAKE_CXX_STANDARD_REQUIRED ON so the build fails loudly on toolchains that cannot do C++14, rather than silently falling back. - Drop the -std=c++11 fragment from both REL and DBG CMAKE_CXX_FLAGS lines. C and C11 are left alone (C11 remains the C floor). Not touched in this commit: - examples/**/CMakeLists.txt and wrappers/obj-c/CMakeLists.txt also pin -std=c++11. Those are standalone sample/wrapper build scripts not wired via add_subdirectory and not built by any CI workflow; their pins are intentional statements of each sample's minimum and can stay. - This commit does not bump the project to C++17. Cleanup ideas like cpp_client_telemetry_modules#302 (std::string::data() -> char*) require C++17 and are still out of scope. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Added commit Why it fits this PR's "remove stale references" theme:
Toolchain risk: gcc-5+, clang-3.4+, and MSVC 2015+ all fully support C++14. The original comment ("…we may get C++11 on older gcc-4.x and gcc-5.x") is a 7-year-old caveat that no realistic build environment hits today. I also added Out of scope (intentional):
PR description's "What changes" list updated to mention this; no other text changes needed. |
Derive package version components from MATSDK_BUILD_VERSION so CPack packages stay aligned with the SDK version. Use PROJECT_SOURCE_DIR and PROJECT_BINARY_DIR for test CMake paths so the SDK remains subproject-friendly. Files changed: - CMakeLists.txt - tools/MakeDeb.cmake - tools/MakeRpm.cmake - tools/MakeTgz.cmake - tests/functests/CMakeLists.txt - tests/unittests/CMakeLists.txt Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Validate MATSDK_BUILD_VERSION before deriving CPack version components and remove now-dead DAYNUMBER calculations from package scripts. Files changed: - CMakeLists.txt - tools/MakeDeb.cmake - tools/MakeRpm.cmake - tools/MakeTgz.cmake Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
# Conflicts: # lib/CMakeLists.txt
The previous merge from main left a conflict marker block in lib/CMakeLists.txt's trailing commented-link section. Remove the marker block and keep the cleaned-up file content. Files changed: - lib/CMakeLists.txt Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Keep package script version cleanup out of the CMake cleanup PR; package version alignment can be handled separately before the next release. Files changed: - CMakeLists.txt - tools/MakeDeb.cmake - tools/MakeRpm.cmake - tools/MakeTgz.cmake Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add an explicit VS2026/v145 command-line build entry alongside the existing VS2022/v143 script so Windows consumers can choose the right supported toolset without guessing from MSBuild internals. Files changed: - docs/cpp-start-windows.md - build-all-v145.bat - tools/vcvars.cmd - Solutions/before.targets Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This reverts commit b99ff14.
|
Sorry, pushed a commit to this branch by accident, so have reverted it. |
Pure build/project cleanup
CMake improvements (3 files)
Cleanup / CMake hygiene
LANGUAGES C CXXto the top-levelproject()callmessage(STATUS ...)instead of baremessage(...)message(FATAL_ERROR, ...)comma bug (invalid CMake syntax)if(EXISTS ...)quoting inlib/,tests/functests/, andtests/unittestsconfigure_file(... COPYONLY)Solutions/before.targetsandSolutions/build.MIP.propsMATSDK_API_VERSIONfrom 3.4 to 3.10 to match recent releases-fPICflags preservedinclude_directoriesentryVisual Studio project cleanup (8 files)
targetver.h(SampleCpp, SampleCppMini)LogManagerV1.hpp(Shared.vcxitems)MockILocalStorageReader.hpp(UnitTests.vcxproj)SanitizerBaseTests.cpp(FuncTests.vcxproj)Packaging