libcamera use the nlohmann_json wrap indirectly through libpisp. This
causes the nlohmann_json.wrap being copied to /subprojects at configure
time, and nlohmann_json being downloaded to /nlohmann_json-3.11.2. Add
an entryto .gitignore to cover both.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
The libyuv wrap uses a libyuv commit between versions 1770 and 1772,
more than 5 years old. This specifies CMake 2.8 as the minimum required
version.
The most recent CMake has dropped compatibility with versions older than
3.5 in CMake 4.0. CMake 3.5 was released in 2016, and all distributions
we care about ship more recent versions. With CMake 4.0 or newer,
shipped for instance by Gentoo, compilation of the libyuv wrap fails.
Update the wrap to version 1922, which is the latest numbered version
(libyuv doesn't tag release by increases a version number in the
README.chromium file). This requires CMake 3.16, released 6 years ago,
and available in at least the last two LTS of major distributions.
This update introduces two issues. First, due to a bug in Meson (see
https://github.com/mesonbuild/meson/issues/10764), PIC handling is
broken when a CMake project wraps a static library into another static
library that has no additional source file. Work around it by wrapping
the libyuv static library again, manually setting 'pic' to true.
The second issue is that libyuv fails to compile for armhf platforms
that don't support NEON instructions. This is the case on Debian 12 and
13 that ship armhf toolchains with NEON disabled by default. The issue
causes CI failures. As the libyuv wrap is a convenience measure, disable
NEON optimization on armfd platforms the same way Debian does in its
armhf packages. If NEON support is important, the build environment
should provide a suitable libyuv.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Commit a29c53f6a6 ("meson: Use libyaml wrap file from wrapdb")
modified the libyaml wrap in a way that resulted in the subproject
source code being stored in a different subdirectory, but didn't update
.gitignore accordingly. Fix it.
Fixes: a29c53f6a6 ("meson: Use libyaml wrap file from wrapdb")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Use the libyaml wrap file from the meson wrapdb instead of
creating the wrap file manually and using the cmake module.
This provides better integration with meson, such as the
`force_fallback_for` built-in option.
This is also needed because the upstream CMakeLists.txt is
out of date, failing with a sufficiently new cmake version:
CMake Error at CMakeLists.txt:2 (cmake_minimum_required):
Compatibility with CMake < 3.5 has been removed from CMake.
The above is nonetheless addressed by https://github.com/yaml/libyaml/pull/314,
but the project seems a bit inactive at the moment.
The wrap file was added using `meson wrap install libyaml`,
and it can be updated using `meson wrap update libyaml`.
`default_library=static` is used to match the behaviour of the
previously used cmake build. `werror=false` needs to be set
because libyaml does not compile without warnings, and that
would abort the build process otherwise.
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
We are using pybind11 'smart_holder' branch to solve the Camera
destructor issue (see the comment in this patch, or the commit
that originally added Python bindings support).
As it would be very nice to use the mainline pybind11 (which is packaged
in distributions), this patch adds a workaround allowing us to move to
the mainline pybind11 version.
The workaround is simply creating a custom holder class
(PyCameraSmartPtr), used only for the Camera, which wraps around the
shared_ptr. This makes the compiler happy.
Moving to mainline pybind11 is achieved with:
- Change the pybind11 wrap to point to the mainline pybdind11 version
- Tell pybind11 to always use shared_ptr<> as the holder for
PyCameraManager, as we use the singleton pattern for the
PyCameraManager, and using shared_ptr<> to manage it is a requirement
- Tell pybind11 to always use PyCameraSmartPtr<> as the holder for Camera
- Change the meson.build file to use a system-installed pybind11
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Miscellaneous files that are not considered copyrightable are missing an
SPDX-License-Identifier header. Fix this by adding a header listing the
CC0-1.0 license.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Add libcamera Python bindings. pybind11 is used to generate the C++ <->
Python layer.
We use pybind11 'smart_holder' version to avoid issues with private
destructors and shared_ptr. There is also an alternative solution here:
https://github.com/pybind/pybind11/pull/2067
Only a subset of libcamera classes are exposed. Implementing and testing
the wrapper classes is challenging, and as such only classes that I have
needed have been added so far.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
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>
Android HAL adaptation layer may need image processing, for
example, scaling and format conversion. Libyuv is a general image
processing. This adds libyuv to subprojects, so that it is forked
locally and can be used with Android HAL implementation code.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
