| Age | Commit message (Collapse) | Author |
|---|
|
Move the GPL2 utilities which handle generation of controls, formats and
the top level libcamera header to the utils subtree.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
The gen-header.sh script that generates libcamera.h takes all .h files
in the include/libcamera/ directory, and manually adds the generated
control_ids.h and version.h. This is fragile, as shown by the failure to
add property_ids.h to the list in commit f870591a9bf5 ("libcamera:
properties: Add location property").
To avoid future omissions, take all the .h.in files into account to
generate libcamera.h. This also fixes the missing property_ids.h.
Fixes: f870591a9bf5 ("libcamera: properties: Add location property")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Bring back auto-generation of control ids. In this version, both the
header and the source files are generated from a single YAML file that
stores all control definitions. This allows centralising controls in a
single file, while the previous version required keeping both
declarations (in a header) and documentation (in a the source) in sync
manually.
Using YAML as a format to store control definitions is a trade-off
between ease of use (there are many YAML parsers available) and
simplicity (XML was considered, but would have lead to more complex
processing). A new build time dependency is added on python3-yaml, which
should be available as a package in all distributions and build
environments.
The YAML format is likely to change over time as we improve
documentation of controls, the first version simply copies the
information currently available. Future improvements should also include
a YAML schema to validate the YAML source file.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Commit b817bcec6b53 ("libcamera: Auto generate version information")
generates version information in order to automatically include it
various locations (Sphinx and Doxygen documentation, libcamera::version
variable available at runtime, and version.h available at compile time).
Unfortunately this causes lots of unnecessary rebuilds when modifying
the git tree state, which hinders development.
The problem is caused by the generated version.h being listed as a
dependency for the whole libcamera. This is required as meson (to the
best of my knowledge) doesn't provide a way to explicitly specify the
dependency of a single object file (camera_manager.o in this case, as
camera_manager.cpp is the only consumer of the generated version string)
on the custom target used to generate version.h. The dependency can't be
automatically detected at build time, like dependencies on normal
headers that are generated by parsing the source, because the version.h
header may not exist yet. The build could then fail in a racy way.
This change attempts at solving the issue by generating a version.cpp
instead of a version.h to set the git-based version. This minimises the
number of files that need to be rebuild when then git tree state
changes, while retaining the main purpose of the original automatic
version generation, the ability to access the git-based version string
at runtime. We however lose the ability to access git-based version
information at build time in an application building against libcamera,
but there is no expected use case for this.
The version string is moved from the libcamera namespace to the
CameraManager class in order to avoid including version.h inside
libcamera (in version.cpp and in camera_manager.cpp), which would create
dependencies causing more rebuild steps, as described above.
On the other hand, major, minor and patch level version numbers are
useful at build time. This commit changes the generation of version.h in
order to add three macros named LIBCAMERA_VERSION_MAJOR,
LIBCAMERA_VERSION_MINOR and LIBCAMERA_VERSION_PATCH for this purpose.
version.h is not included by any other libcamera header or source file,
and thus doesn't force a rebuild of the library.
The Sphinx and Doxygen documentation keep their git-based version
information, which is set during the configuration of the build and then
doesn't track git commits. We may want to investigate how to improve
this, but given that git-based version for the documentation has very
few use cases outside of tagging nightly builds, this isn't considered
an issue at the moment.
The documentation install directory now uses the base version string, in
order to avoid increasing the number of documentation directories
needlessly. This shouldn't cause any issue as the API should not change
without a change to the version number.
The version number generation and handling code now also standardises
the version variables to not start with a 'v' prefix in meson, in order
to simplify their handling. The prefix is added when generating the
relevant files.
Note that we go back to specifying the fallback version in the main
meson.build, in the call to the project() function. For the time being I
believe this should be a good compromise to avoid unnecessary
recompilation, and moving the fallback version to a different file for
tarball releases can be built on top of this.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
As shown by two missing includes, keeping the libcamera.h file in sync
when adding or removing headers is an error-prone manual process.
Automate it by generating the header automatically.
The libcamera.h header is also added to the libcamera dependency
libcamera_dep to ensure that the headers gets generated before any
source depending on it gets compiled.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
