Is your feature request related to a problem? Please describe.
Presently, the json parser library Parson singlehandedly is used to generate libgrass_parson.[so/dylib], making its API directly a part of GRASS public API.
Recent work on #4665, have revealed compatibility issues with this approach. GDAL has embedded JSON-C code, which API in part overlaps that of Parson's, causing conflicts upon linking the libgrass_parson and GDAL at the same time.
Describe the solution you'd like
In order to overcome this conflict, we could create a thin wrapper of the json parser (in this case Parson) with a unique GRASS API (with the potential additional advantage of not being completely hooked up to the use of the Parson library).
Additional context
Initially I'm thinking of wrapping function that are in use, or are likely to be used in this way json_value_init_object()-> G_json_value_init_object().
List (not complete) of relevant functions to wrap up :
- json_value_get_object
- json_value_init_array
- json_value_init_object
- json_object
- json_object_get_array
- json_object_get_wrapping_value
- json_object_set_boolean
- json_object_set_null
- json_object_set_number
- json_object_set_string
- json_object_set_value
- json_array_append_string
- json_array_append_value
- json_serialize_to_string_pretty
- json_free_serialized_string
- json_value_free
How to deal with Parson "types" such as JSON_Object, JSON_Array and JSON_Value, whether to wrap them too or just "re-use" them, needs to be decided.
Is your feature request related to a problem? Please describe.
Presently, the json parser library Parson singlehandedly is used to generate
libgrass_parson.[so/dylib], making its API directly a part of GRASS public API.Recent work on #4665, have revealed compatibility issues with this approach. GDAL has embedded JSON-C code, which API in part overlaps that of Parson's, causing conflicts upon linking the libgrass_parson and GDAL at the same time.
Describe the solution you'd like
In order to overcome this conflict, we could create a thin wrapper of the json parser (in this case Parson) with a unique GRASS API (with the potential additional advantage of not being completely hooked up to the use of the Parson library).
Additional context
Initially I'm thinking of wrapping function that are in use, or are likely to be used in this way
json_value_init_object()->G_json_value_init_object().List (not complete) of relevant functions to wrap up :
How to deal with Parson "types" such as JSON_Object, JSON_Array and JSON_Value, whether to wrap them too or just "re-use" them, needs to be decided.