[libcamera-devel] [RFC 0/2] Add new build option to override generate SHA

[Laurent Pinchart]

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