<div dir="ltr"><div dir="ltr">Hi Laurent,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 12 Oct 2021 at 21:05, Laurent Pinchart <<a href="mailto:laurent.pinchart@ideasonboard.com">laurent.pinchart@ideasonboard.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Naush,<br>
<br>
Thank you for the patches.<br>
<br>
On Tue, Oct 12, 2021 at 04:24:08PM +0100, Naushir Patuck wrote:<br>
> Hi,<br>
> <br>
> This set of changes have come about after a discusion on an issue raised on the Pi<br>
> libcamera-apps github repo [1]. From my little understanding, various distributions<br>
> use different methods to build and package libraries. As part of this process,<br>
> they may build these libraries outside of the upstream tree, and perhaps not<br>
> even in a git repo tree. If this happens, the version string generated during the<br>
> libcamera build is either empty or (if it is from a downstream tree) useless.<br>
> <br>
> This change allows the user to override the SHA value with a string passed into<br>
> the meson build options that would be used in-place of the one generated by the<br>
> gen-version.sh script. This would allow out-of-tree builds to provide a sensible<br>
> sha version string based off the upstream tree.<br>
> <br>
> I'm not too sure if this is the best way to do this, but it is a simple solution.<br>
> If anyone has other suggestions how we can overcome this, please do let me know.<br>
<br>
We're stepping in the wonderful world of release management :-)<br>
<br>
We'll certainly need to support builds from release tarballs, that's how<br>
most distributions will handle it. We've mostly ignored the issue until<br>
now as we have no tagged release, so there was no urgency, but it<br>
doesn't mean we have to wait before solving this problem.<br>
<br>
Once we'll have releases, we will have a version number stored in the<br>
top-level meson.build file. The gen-version.sh script will return an<br>
empty string, so only the release version will be used. That's been<br>
assumed so far to cover all the needs, as if there's an official<br>
release, tags and branches in the repository can be used to find the<br>
exact commit that was used to generate the tarball.<br>
<br>
What we haven't considered is builds from tarballs that do not<br>
correspond to official releases. In those cases, the binary will report<br>
the version number of the last tag, without any sign of local changes.</blockquote><div><br></div><div>This is probably the most likely mode of release for RPi :)</div><div><br></div><div> I wonder if we could improve this by automating SHA handling in that case,</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
by automatically adding a file to the tarball when running 'meson dist'<br>
with the git commit ID. That file would be read by gen-version.sh if<br>
present. That way, generated tarballs will point to a particular commit,<br>
and the process should be less error-prone as there won't be any need to<br>
set a meson option manually.<br></blockquote><div><br></div><div>Thanks for the tips! I have read up on meson dist and think I have something</div><div>that will suit our needs better. In summary, the meson dist will run a script</div><div>that generates the version string (with utils/gen-version.sh) and saves it into</div><div>the distro tarball. I then will need to update the top level meson.build to</div><div>read the version from the version.gen file if it exists, otherwise generate</div><div>it as normal.</div><div><br></div><div>The Filesystem modele in meson has a handy fs.read() function, but requires</div><div>me to bump up the minimum meson version from 0.55 to 0.57 so I will</div><div>just do a cat and pipe command to read the version string from the file.</div><div><br></div><div>I will prepare a change and we can discuss it in more detail.</div><div><br></div><div>Regards,</div><div>Naush</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
There are probably a few things details to be figured out (for instance,<br>
if the HEAD commit corresponds to a release tag, we likely want to skip<br>
inclusion of the SHA1, so maybe the commit ID file should actually be a<br>
.version file that stores the output of gen-version.sh), but what do you<br>
think of the idea overall ?<br>
<br>
> [1]: <a href="https://github.com/raspberrypi/libcamera-apps/issues/122" rel="noreferrer" target="_blank">https://github.com/raspberrypi/libcamera-apps/issues/122</a><br>
> <br>
> Naushir Patuck (2):<br>
> utils: Add an option to override SHA string in gen-version.sh<br>
> build: Add a "version_sha" meson build option<br>
> <br>
> meson.build | 4 +++-<br>
> meson_options.txt | 5 +++++<br>
> src/libcamera/meson.build | 3 ++-<br>
> utils/gen-version.sh | 25 ++++++++++++++++++-------<br>
> 4 files changed, 28 insertions(+), 9 deletions(-)<br>
<br>
-- <br>
Regards,<br>
<br>
Laurent Pinchart<br>
</blockquote></div></div>