|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk