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

[Jakob Reschke]

I can only guess that the default source tarball and zip that GitHub
creates is not an output of a git-archive-like subroutine, or that
GitHub generally does not run any filters from .gitattributes (maybe
for security reasons).

If that is so, we would rather need to create a tarball by ourselves
for every release/tag and attach it like the archives for the various
flavors and platforms. That is, check out the sources, run the scripts
or filters, tar the directory that is ready for building. It should be
possible to code this into the CI jobs for releases.

As far as I know, release tarballs should not only be snapshots from
the version control system anyway. For example, in Autotools projects
the release tarball should contain the generated configure script
rather than only the files from the repository, which have to be
processed by Autoconf first, so that anyone who wants to build and
install the release does not need to have the Autotools installed. I
think filling in the version information, and therefore getting rid of
the requirement to have the Git repository in the tarball, plays in
the same league.

Am So., 18. Juli 2021 um 21:24 Uhr schrieb Phil B <pbpublist at gmail.com>:
>
>
> 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