From: Glen Fernandes (glen.fernandes_at_[hidden])
Date: 2024-01-07 20:08:08
On Sun, Jan 7, 2024 at 1:15 PM Peter Dimov wrote:
> Glen Fernandes wrote:
> > On Sun, Jan 7, 2024 at 12:32 PM Peter Dimov wrote:
> >
> >
> > Glen Fernandes wrote:
> > > If we change what goes into the distribution, this is an option.
> As far as
> > I was
> > > told, at our current distribution size, this would require LFS
> which
> > GitHub
> > > would charge us for.
> >
> > https://docs.github.com/en/repositories/releasing-projects-on-
> > github/about-releases
> >
> > says
> >
> > "Each file included in a release must be under 2 GiB. There is no
> limit on
> > the total size of a release, nor bandwidth usage."
> >
> > The currently hosted archives are comparable in size with the
> official
> > releases.
> >
> > The official boost_1_84_0.7z is 106 MB, and the corresponding CMake
> > archive
> > is 90.1 MB.
> >
> >
> >
> > In other words, as long as the GitHub release can be made from our
> existing
> > repository contents, we should be fine?
> >
> > i.e. We cannot put our current official built releases into a GitHub
> repository
> > because any file over 100 MB would be rejected:
> >
> >
> https://docs.github.com/en/repositories/working-with-files/managing-large-
> > files/about-large-files-on-github
> >
> > "GitHub blocks files larger than 100 MiB.
> > To track files beyond this limit, you must use Git Large File Storage
> (Git LFS)."
>
>
> https://github.com/boostorg/boost/releases/download/boost-1.84.0/boost-1.84.0.zip
>
> is 149 MB.
>
> The above probably refers to putting large files in a repository, not to
> release
> artifacts.
>
>
Thanks; then leveraging GitHub releases seems like the best solution to me.
Maybe the only (free) solution we have.
Glen