lobo/aws-sdk-for-zig
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity

update model readme

Browse Source
This commit is contained in:
Emil Lerch 2023-08-25 14:51:33 -07:00
parent 2f36f82363
commit 6a109f2a5a
Signed by: lobo
GPG Key ID: A7B62D657EF764F8
1 changed files with 10 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
codegen/README-models.md
View File

@ -7,19 +7,18 @@ as they do in other languages. We can combine all models from AWS into a single
comptime constant even, however, we're keeping zig files 1:1 with json files comptime constant even, however, we're keeping zig files 1:1 with json files
for now. for now.
The main executable, run with a "-s" first argument, will simply parse the Optimization plan will be done by the placing of a json file in the output
Smithy json files passed by the rest of the arguments and save each one as directory. The json file will contain a mapping between input files and generated
its own file.json.zig. We will rely on shell commands to do the rest of the outputs, as well as a top level directory hash. We can skip the output generation
renaming (and moving if necessary). entirely if the top level hash matches, otherwise, individual hashes will be
compared and output files will only regenerate if the input or output has changed.
To run this, we can use `codegen -s models/*.json`, which takes 20 seconds
or so on my i5 chromebook and probably significantly faster on a real machine. Todo
No attempt has been made to optimize. Also, there are several bugs: ----
* I do not think all the optional types have been sorted. * I do not think all the optional types have been sorted.
* I think there is necessary metadata missing from EC2Query style services * I think there is necessary metadata missing from EC2Query style services
* The output will compile and is close to what `zig fmt` likes to see, but it
has not yet been functionally tested
* It handles all the types in existing AWS services, but it does not handle * It handles all the types in existing AWS services, but it does not handle
all known Smithy types (e.g. blob and document are missing) all known Smithy types (e.g. blob and document are missing)
* It would be awesome to bring over the documentation from the model into * It would be awesome to bring over the documentation from the model into
@ -29,13 +28,7 @@ No attempt has been made to optimize. Also, there are several bugs:
realistically I'm not sure if that will matter long term, and it's a fair realistically I'm not sure if that will matter long term, and it's a fair
amount of work as everything now can be done in a single pass without post amount of work as everything now can be done in a single pass without post
processing. processing.
* This doesn't seem to build on 0.7.1 - you need master branch. I hope that
0.8.0 will be out soon. If not, a few syntax changes need to be accommodated.
Some of these will likely be addressed as I integrate the code generated files into
the SDK engine.
The models are Smithy json files, sourced from the AWS v2 go sdk The models are Smithy json files, sourced from the AWS v2 go sdk
for lack of a better place. I've just downloaded the main branch and copied for lack of a better place. Details are in build.zig of the parent project
the files from the tree in place. that is now responsible for downloading/caching the project.