[Vm-dev] Suggestions for handling sqSCCSVersion.h with tarball builds?

[Phil B]

Jakob,

That appears to be how it's currently set up.  The issue is that the
updateSCCSVersions script is not being run before the tarball is generated
to actually populate the placeholders.  As far as I can tell, as a result
there's no version information in the resulting archive. (i.e.
https://github.com/OpenSmalltalk/opensmalltalk-vm/archive/refs/tags/202003021730.tar.gz
)

For my purposes, the simplest solution would be if updateSCCSVersions were
run immediately before generating the tarball.  But I have no idea if that
would cause problems elsewhere as that would depend on how the backend
generating it is set up and/or what assumptions are being made by anything
that might run after the tarball is generated.

Thanks,
Phil

On Sun, Jul 18, 2021 at 2:24 AM Jakob Reschke <jakres+squeak at gmail.com>
wrote:

>
> Hi Phil,
>
> I think usually git-archive + smudge filters in .gitattributes for the
> version numbers are the solution.
>
> Is that an option here?
>
> Kind regards,
> Jakob
>
> Phil B <pbpublist at gmail.com> schrieb am So., 18. Juli 2021, 03:04:
>
>>
>> I am working on packaging up the VM for Debian and related distros.  My
>> current approach is to download the stable tarball release from
>> https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/latest.  The
>> problem I'm having is that unless manual hacks are applied each time it is
>> downloaded, the build will fail since platforms/Cross/vm/sqSCCSVersion.h
>> has not been updated and the script to update it fails as the tarball is
>> just a snapshot of the source files rather than a clone of the repo. (the
>> snapshot is actually what is preferred vs a repo clone from a Debian
>> packaging standpoint)
>>
>> Ideally, the generated tarball would include a pre-updated
>> sqSCCSVersion.h since this is a point in time snapshot.  Is this something
>> that makes sense and could be changed for the generated tarball?  If not,
>> any suggestions on how to handle this in an automated way for tarball
>> builds?  If I should be sourcing the tarball a different way, I'm open to
>> that as well.
>>
>> Thanks,
>> Phil
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20210718/f9eb7b3a/attachment.html>