[libcamera-devel] [RFC 0/2] Add new build option to override generate SHA
Laurent Pinchart
laurent.pinchart at ideasonboard.com
Tue Oct 12 22:30:17 CEST 2021
On Tue, Oct 12, 2021 at 11:05:00PM +0300, Laurent Pinchart wrote:
> Hi Naush,
>
> Thank you for the patches.
>
> On Tue, Oct 12, 2021 at 04:24:08PM +0100, Naushir Patuck wrote:
> > Hi,
> >
> > This set of changes have come about after a discusion on an issue raised on the Pi
> > libcamera-apps github repo [1]. From my little understanding, various distributions
> > use different methods to build and package libraries. As part of this process,
> > they may build these libraries outside of the upstream tree, and perhaps not
> > even in a git repo tree. If this happens, the version string generated during the
> > libcamera build is either empty or (if it is from a downstream tree) useless.
> >
> > This change allows the user to override the SHA value with a string passed into
> > the meson build options that would be used in-place of the one generated by the
> > gen-version.sh script. This would allow out-of-tree builds to provide a sensible
> > sha version string based off the upstream tree.
> >
> > I'm not too sure if this is the best way to do this, but it is a simple solution.
> > If anyone has other suggestions how we can overcome this, please do let me know.
>
> We're stepping in the wonderful world of release management :-)
>
> We'll certainly need to support builds from release tarballs, that's how
> most distributions will handle it. We've mostly ignored the issue until
> now as we have no tagged release, so there was no urgency, but it
> doesn't mean we have to wait before solving this problem.
>
> Once we'll have releases, we will have a version number stored in the
> top-level meson.build file. The gen-version.sh script will return an
> empty string, so only the release version will be used. That's been
> assumed so far to cover all the needs, as if there's an official
> release, tags and branches in the repository can be used to find the
> exact commit that was used to generate the tarball.
>
> What we haven't considered is builds from tarballs that do not
> correspond to official releases. In those cases, the binary will report
> the version number of the last tag, without any sign of local changes. I
> wonder if we could improve this by automating SHA handling in that case,
> by automatically adding a file to the tarball when running 'meson dist'
> with the git commit ID. That file would be read by gen-version.sh if
> present. That way, generated tarballs will point to a particular commit,
> and the process should be less error-prone as there won't be any need to
> set a meson option manually.
>
> There are probably a few things details to be figured out (for instance,
> if the HEAD commit corresponds to a release tag, we likely want to skip
> inclusion of the SHA1, so maybe the commit ID file should actually be a
> .version file that stores the output of gen-version.sh), but what do you
> think of the idea overall ?
This could be implemented with a new script in utils/ that gets run by
`meson dist` through meson.add_dist_script() ([1]).
[1] https://mesonbuild.com/Reference-manual_builtin_meson.html#mesonadd_dist_script
> > [1]: https://github.com/raspberrypi/libcamera-apps/issues/122
> >
> > Naushir Patuck (2):
> > utils: Add an option to override SHA string in gen-version.sh
> > build: Add a "version_sha" meson build option
> >
> > meson.build | 4 +++-
> > meson_options.txt | 5 +++++
> > src/libcamera/meson.build | 3 ++-
> > utils/gen-version.sh | 25 ++++++++++++++++++-------
> > 4 files changed, 28 insertions(+), 9 deletions(-)
--
Regards,
Laurent Pinchart
More information about the libcamera-devel
mailing list