summaryrefslogtreecommitdiff
path: root/test/serialization/generated_serializer/meson.build
diff options
context:
space:
mode:
authorLaurent Pinchart <laurent.pinchart@ideasonboard.com>2024-08-07 19:31:34 +0300
committerLaurent Pinchart <laurent.pinchart@ideasonboard.com>2024-08-15 04:44:09 +0300
commitb8d318ebeba0710d5a7f8292a02570bb9a886f8b (patch)
tree6d640add70e891f7be19c29332ab29cbc0e1f551 /test/serialization/generated_serializer/meson.build
parent53108b6ff1c5ea93bee9f8c5329c840e24f24a8d (diff)
meson: Store controls and properties YAML files in variables
When generating control headers, the YAML files to be used are determined dynamically based on the selected pipeline handlers. As part of this process, the build system populates an array of meson File objects used as an input for the control headers generation custom target, as well as an array of file names (as strings). The file names array is later used to generate the control source files for the libcamera core, as well as the source code for controls support in the Python bindings. Both of the source code generators manually turn the array of file names into File objects. This duplicates code and reduces readability. A third similar implementation has also been proposed to generate control support sources in the GStreamer element, making the issue worse. To simplify this, store File objects instead of file names in the controls_files array. As the meson configuration summary doesn't support File objects, create a separate controls_files_names to store the file names for that sole purpose. The exact same process occurs for properties, address them the same way. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Diffstat (limited to 'test/serialization/generated_serializer/meson.build')
0 files changed, 0 insertions, 0 deletions