Allow packaging the C++ client in Debug mode (-Dcmake.build.type=Debug)

[JackieTien97]

What

Make -Dcmake.build.type=Debug actually produce a debug build of the C++ client library (libiotdb_session).

Why

On non-MSVC platforms, iotdb-client/client-cpp/src/main/CMakeLists.txt hardcoded:

SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -g -O2")

and the cmake-generate step in pom.xml never passed -DCMAKE_BUILD_TYPE. Single-config generators (e.g. Unix Makefiles) ignore cmake --build --config, so on Linux/macOS the existing cmake.build.type property was effectively a no-op — the packaged library was always compiled at -O2. Even -DCMAKE_BUILD_TYPE=Debug stayed at -O2, because Debug only appends -g and never removes the hardcoded -O2.

How

• pom.xml: pass -DCMAKE_BUILD_TYPE=${cmake.build.type} to the main-library cmake-generate execution.
• src/main/CMakeLists.txt: stop hardcoding the optimization level. Keep -Wall -g for all build types (Release still ships symbols, as before), set CMAKE_CXX_FLAGS_RELEASE to -O2 and CMAKE_CXX_FLAGS_DEBUG to -O0, and default to Release when no type is given.

Release output is intentionally unchanged (-g -O2, no -DNDEBUG, asserts still active). MSVC is unaffected — it already selects the configuration via cmake --build --config ${cmake.build.type}.

Usage

# Release (default, unchanged)
mvn clean package -P with-cpp -pl iotdb-client/client-cpp -am -DskipTests

# Debug package
mvn clean package -P with-cpp -pl iotdb-client/client-cpp -am -DskipTests -Dcmake.build.type=Debug

Verification

Actual CXX_FLAGS produced by the configure step (macOS, Unix Makefiles) with these changes:

build type	resulting flags	opt level
default / Release	-Wall -g -O2 ...	-O2 (unchanged)
Debug	-Wall -g -O0 ...	-O0

A full Debug build of libiotdb_session compiles and links; the resulting dylib is ~6.7 MB vs ~3.2 MB for Release, consistent with -O0 + debug info.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Caideyipi]

This should preserve existing per-config flags instead of replacing them completely. Once the POM passes -DCMAKE_BUILD_TYPE, CMAKE_CXX_FLAGS_RELEASE / CMAKE_CXX_FLAGS_DEBUG are actually used, so these unconditional assignments can discard flags provided by a toolchain file or by the caller, e.g. hardening, sanitizer, ABI, or architecture flags. Could we keep the caller/toolchain-provided value and only adjust the optimization level needed here (-O2 for Release, -O0 for Debug)?