summaryrefslogtreecommitdiff
path: root/src/lc-compliance/meson.build
AgeCommit message (Collapse)Author
2022-02-03lc-compliance: Only download gtest subproject as a fallbackJavier Martinez Canillas
Currently, a subproject is used to fetch gtest dependency unconditionally for any Linux distribution besides ChromeOS. But it leads to a regression in distros whose builders are not allowed to download files during build. This change was introduced by commit 0d50a04cc918 ("lc-compliance: Build with gtest in subprojects") and the rationale is that some distros, such as Debian ship libgtest-dev as a static library. And this could be built with a different toolchain than the one used to build libcamera itself. But this seems to be a corner case, usually users will either build both libcamera and all its dependencies using the same toolchain or build it using both the libgtest library and toolchain as provided by the distro. If someone doesn't want for meson to pick up the non-compatible static library provided by the distro, then instead should make sure that their build root does not have the package providing this installed. Let's simplify the logic to find the dependency and just use the built-in support in dependency() function to fallback to a subproject if not found. This covers to common case of attempting to use the gtest provided by the system or pulling from source if not found or is not preferred. To force meson to fallback to the wrap for gtest you can use this command: meson configure -Dforce_fallback_for=gtest and to force fallback for all the dependencies, you can use the following: meson build --wrap-mode=forcefallback Fixes: commit 0d50a04cc918 ("lc-compliance: Build with gtest in subprojects") Reported-by: Eric Curtin <ecurtin@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-11-15lc-compliance: Build with gtest in subprojectsHirokazu Honda
libgtest-dev is provided as a static library at least by Debian 10. The compiler and linker to create the static library might be different from ones used for libcamera. This causes a problem upon linking. This puts gtest code to subprojects, builds the code and link it for lc-compliance. However, libgtest is locally built as a library on ChromeOS and thus the used compiler and linker are the same as one used for libcamera. We don't do these on ChromeOS build environment. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Tested-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-07-06lc-compliance: Refactor using GoogletestNícolas F. R. A. Prado
Refactor lc-compliance using Googletest as the test framework. Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-07-06lc-compliance: Add Environment singletonNícolas F. R. A. Prado
Add a singleton Environment class in order to make the camera available inside all tests. This is needed for the Googletest refactor, otherwise the tests, which are statically declared, won't be able to access the camera. Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-06-25libcamera: rename public libcamera dependencyKieran Bingham
Now that we have a libcamera_private, make the public only dependency libcamera_public so that it is clear which interface is being linked. Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-04-12lc-compliance: Add a libcamera compliance toolNiklas Söderlund
Add a compliance tool to ease testing of cameras. In contrast to the unit-tests under test/ that aims to test the internal components of libcamera the compliance tool aims to test application use-cases and to some extent the public API. This change adds the boilerplate code of a simple framework for the creation of tests. The tests aim both to demonstrate the tool and to catch real problems. The tests added are: - Test that if one queues exactly N requests to a camera exactly N requests are eventually completed. - Test that a configured camera can be started and stopped multiple times in an attempt to exercise cleanup code paths otherwise not often tested with 'cam' for example. Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>