Yep, I agree with your statement. I'm trying to use this to update a users launch.vs.json and launch.json files when they select a new configuration from CMakePresets.json. I expect I'm going to get some pushback that the updates have "reflowed" a JSON file that does tend to be read by humans. I almost think that we see this behavior in the unit tests themselves - the expected json results are laid out the way a human would expect, but the actual result is that the json nodes are probably being serialized in a native tree order and not related to how they were read in. I'm ok with either closing this issue, or willing to leave it open and I'll submit a PR in the next month or so to just add a comment to documentation and unit tests to document that the output json will not match the input json in it's node order. Your thoughts?
Tested on CMAKE 3.20.5. Any use of SET or REMOVE will cause a "reflow" of the JSON nodes if the JSON contains elements that are not addressable by an index. Simple case:
set (json4 [=[
{
"version": "0.2.1",
"defaults": "this is defaults",
"some": "thing"
}
]=])
string(JSON result7 ERROR_VARIABLE err SET "${json4}" version [=["9.9.9"]=])
message("update version result7: ${result7}")
Produces the following JSON. Note how the updated node has been put on the bottom of the list:
{
"defaults" : "this is defaults",
"some" : "thing",
"version" : "9.9.9"
}
Expected behavior:
{
"version" : "9.9.9",
"defaults" : "this is defaults",
"some" : "thing",
}
In addition if you have an array or object in the JSON then any update to those will cause any un-indexed nodes ahead of it to be reflowed to the bottom of the json. If you run some of the unit tests in the repository you can see that they pass because string(JSON EQUAL) allows the JSON nodes to be in different order for equality. For example this unit test passes but is not what would be expected behavior to a developer reading the test.
This is possibly/likely expected behavior for string(JSON) but it is not documented behavior and can lead to confusion. Some of the unit tests could be changed to show the reflowed JSON being used as expected result, and/or text added to the string(JSON) help text. It would be more use friendly if the original order of nodes was maintained - i.e. a more likely expected behavior.