From 2a39ba3d64425dc3991f68f57ab5a8eb69d41f59 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Sun, 5 Oct 2025 03:54:49 +0000 Subject: [PATCH 1/2] Initial plan From edc653df8bfef27b2b379529a0df85c42712169a Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Sun, 5 Oct 2025 04:00:16 +0000 Subject: [PATCH 2/2] Update documentation version references from v4.x to v5.x Co-authored-by: wravery <6502881+wravery@users.noreply.github.com> --- README.md | 4 ++-- doc/migration.md | 8 ++++---- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index a3a0b6e8..2c84b02d 100644 --- a/README.md +++ b/README.md @@ -216,9 +216,9 @@ There are several helper functions for `CMake` declared in other samples sub-directories for examples of how to use them to automatically rerun the code generators and update the files in your source directory. -### Migrating from v3.x to main +### Migrating from v4.x to main -Please see the [Migration Guide for v4.x](./doc/migration.md) for more details about upgrading to from the `v3.x` branch +Please see the [Migration Guide for v5.x](./doc/migration.md) for more details about upgrading to from the `v4.x` branch to the `main` branch. Active development takes place almost entirely in `main`. ### Additional Documentation diff --git a/doc/migration.md b/doc/migration.md index fe74110e..2b6c9e1c 100644 --- a/doc/migration.md +++ b/doc/migration.md @@ -1,6 +1,6 @@ -# Migration Guide for v4.x +# Migration Guide for v5.x -Most of the changes in v4.x affect services generated with `schemagen` more than clients generated with `clientgen`. +Most of the changes in v5.x affect services generated with `schemagen` more than clients generated with `clientgen`. ## Adopting C++20 @@ -159,7 +159,7 @@ By default, earlier versions of `schemagen` would generate a single header and a For a long time, `schemagen` also supported a `--separate-files` flag which would output a separate header and source file for each object type in the schema. This requires more complicated build logic since the set of files that need to be built can change based on the schema, but the end result is much easier to read and incremental builds are faster. -In v4.x, the separate files option is not only the default, it's the only option. Supporting both modes of code generation would have added too much complexity and too many tradeoffs for the simplified build logic. Instead, v4.x adds several CMake helper functions in [cmake/cppgraphqlgen-functions.cmake](../cmake/cppgraphqlgen-functions.cmake) which encapsulate the best practices for regenerating and building the schema targets dynamically when the schema file changes. These functions are automatically included by `find_package(cppgraphqlgen)`. +In v5.x, the separate files option is not only the default, it's the only option. Supporting both modes of code generation would have added too much complexity and too many tradeoffs for the simplified build logic. Instead, v5.x adds several CMake helper functions in [cmake/cppgraphqlgen-functions.cmake](../cmake/cppgraphqlgen-functions.cmake) which encapsulate the best practices for regenerating and building the schema targets dynamically when the schema file changes. These functions are automatically included by `find_package(cppgraphqlgen)`. Replace custom CMake logic to invoke `schemagen` and `clientgen` with these helper functions: - `update_graphql_schema_files`: Runs `schemagen` with required parameters and additional optional parameters. @@ -173,4 +173,4 @@ Declare library targets which automatically include all of the generated files w - `add_graphql_schema_target`: Declares a library target for the specified schema which depends on the output of `update_graphql_schema_files` and automatically links all of the shared library dependencies needed for a service. - `add_graphql_client_target`: Declares a library target for the specified client which depends on the output of `update_graphql_client_files` and automatically links all of the shared library dependencies needed for a client. -With all of the refactoring in v4.x, there ceased to be any separation between the `graphqlintrospection` and `graphqlservice` libraries. Even if you use the `--no-introspection` flag with `schemagen`, the generated code still depends on the general schema types which remained in `graphqlintrospection` to perform query validation. As part of the v4.x release, the 2 libraries were combined back into a single `graphqlservice` target. If you use `add_graphql_schema_target` you do not need to worry about this, otherwise you should replace any references to just `graphqlintrospection` with `graphqlservice`. +With all of the refactoring in v5.x, there ceased to be any separation between the `graphqlintrospection` and `graphqlservice` libraries. Even if you use the `--no-introspection` flag with `schemagen`, the generated code still depends on the general schema types which remained in `graphqlintrospection` to perform query validation. As part of the v5.x release, the 2 libraries were combined back into a single `graphqlservice` target. If you use `add_graphql_schema_target` you do not need to worry about this, otherwise you should replace any references to just `graphqlintrospection` with `graphqlservice`.