<div dir="ltr"><div dir="ltr">Hi Laurent,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 13 Oct 2021 at 11:08, 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>
On Wed, Oct 13, 2021 at 10:48:17AM +0100, Naushir Patuck wrote:<br>
> On Tue, 12 Oct 2021 at 21:05, Laurent Pinchart wrote:<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.<br>
> <br>
> This is probably the most likely mode of release for RPi :)<br>
> <br>
> I wonder if we could improve this by automating SHA handling in that case,<br>
> <br>
> > 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>
> <br>
> Thanks for the tips! I have read up on meson dist and think I have something<br>
> that will suit our needs better. In summary, the meson dist will run a script<br>
> that generates the version string (with utils/gen-version.sh) and saves it into<br>
> the distro tarball. I then will need to update the top level meson.build to<br>
> read the version from the version.gen file if it exists, otherwise generate<br>
> it as normal.<br>
> <br>
> The Filesystem modele in meson has a handy fs.read() function, but requires<br>
> me to bump up the minimum meson version from 0.55 to 0.57 so I will<br>
> just do a cat and pipe command to read the version string from the file.<br>
<br>
We try not to depend on meson versions that are not available in the<br>
latest stable release of the major distributions.</blockquote><div><br></div><div>Agree, I don't want to bump up the version just to use that function.</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">In this case, I would<br>
thus prefer handling this through a script. Would it make sense to<br>
modify gen-version.sh to read the version file when the directory is not<br>
under git's control ?<br></blockquote><div><br></div><div>This is possible, or I can simply do a run_command('cat ...').stdout() to</div><div>read the file. I am about to post a RFC patch with the changes in the next</div><div>few minutes. We can discuss the implementation further there.</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>
> I will prepare a change and we can discuss it in more detail.<br>
> <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>