Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
8 changes: 4 additions & 4 deletions doc/migration.md
Original file line number Diff line number Diff line change
@@ -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

Expand Down Expand Up @@ -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.
Expand All @@ -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`.