Kokoro changes:
- Linux: gcc-13, cmake-3.31.2
- Windows: python 3.12, cmake-3.31.2
* Disable warnings in gtest, gmock
This is required in order to build with GCC 13, and Apple Clang with warnings-as-errors
Bug: crbug.com/383538610
* disable license check on .github/workflows/main.yml
* Use add_subdirectory for internal gtest, gmock
---------
Co-authored-by: Antonio Maiorano <amaiorano@google.com>
The argument in the corresponding if() was changed in
commit ae76a38. CMake emits a warning.
Modern CMake style guides advice on ommitting endif()
arguments.
The `CPPDAP_JSON_{NLOHMANN,RAPID}` compile definition is used only in
cppdap's implementation sources, and does not need to be defined by
dependents including our headers.
Also avoid exposing `nlohmann_json::nlohmann_json` as a public link
dependency of our installed package. It is used only when compiling
cppdap.
* CMake: Fix target options
* update CMake package version after protocol sync
* Update protocol to 1.59.0
* protocol_gen: change OneOf to `object` type
The DAP spec introduces ambiguities with its particular uses of OneOf,
which means that we can't deserialize the variants generated from it.
Just set OneOf to an `object` type, like godap does.
Add options to link against external JSON libraries
This adds two options to the CMake config:
`CPPDAP_USE_EXTERNAL_NLOHMANN_JSON_PACKAGE` and `CPPDAP_USE_EXTERNAL_RAPIDJSON_PACKAGE`
If either of these is set, instead of using the json submodule, the build will be configured by using `find_package()` and linking against the specified JSON library.
CMake installation target has been broken for years.
cppdap is only internally used and tested as a library that is included as a sub-module of another project.
In order for a package to be installable, it really needs a stable ABI / API, which we've made no explicit guarantees about.
cppdap is small enough that it can easily be included in a third_party directory of another project.
Remove the broken, unmaintained installation rules.
Fixes: #54
If any of the `CPPDAP_?SAN` sanitizers are enabled, then the build would fail as the compile flags would collide with hard-coded use of address sanitizer for the fuzzer.
Don't hard code address sanitizer for the fuzzer - just use the CMake flag options.
`DAP_IMPLEMENT_STRUCT_TYPEINFO_EXT` and `DAP_STRUCT_TYPEINFO_EXT` are two new flavors of `DAP_IMPLEMENT_STRUCT_TYPEINFO` and `DAP_STRUCT_TYPEINFO` that allow you to derive message types.
This involved a bit of reworking on the serializer interfaces.
Added test.
Issue: #32
Without this the vscode extension cannot find the example executable, and the example fails.
Also use $USERPROFILE instead of $HOME for finding the `.vscode` user directory for installing the extension.
Bug: #12
`nlohmann/json` raises a `size_t` to `int` MSVC warning that will fail the build if `CPPDAP_WARNINGS_AS_ERRORS` is enabled.
Given that this is not our code, the best we can do is to make an exception for this warning.
