Re: Boost tarball release that works with CMake

From: Mojca Miklavec (mojca.miklavec.lists_at_[hidden])
Date: 2022-11-16 07:25:33

Hi,

See my previous email in the thread. I'm just shortly amending some of
the points.

On Wed, 16 Nov 2022 at 07:20, Gavin Lambert via Boost wrote:
>
> It seems likely that a full clean git clone (even at --depth 1) would
> consume a significantly larger amount of bandwidth than downloading
> tarballs would.

Yes.

> But github has no specific bandwidth limits other than
> "if we notice you, we might do something about it", so you may get away
> with things you shouldn't.

Wouldn't the same apply to releasing the tarball(s) on the github
releases page then?

> Either method could be improved with caching -- the tarball could be
> cached for all individual library CI jobs from the same commit, and one
> set of git clones could be reused similarly.

While I have no problem caching the tarball, I have absolutely no idea
how to do the same with git even on my personal computer.
There is a small hack called "FETCHCONTENT_UPDATES_DISCONNECTED" that
helps a bit on my local machine, but it seems unlikely that it could
have any use inside a GitHub action.

> Git does win a bit more when only building a subset of libraries, or if
> the CI caches the clone and performs an incremental checkout rather than
> a full reclone (although that only provides benefit when *not* using
> --depth 1, which is otherwise better).  (These *could* be supported with
> tarballs too, but only with more difficulty and complex delta-file
> management, which isn't really worth the effort when an alternative exists.)

Please note that we have no reason to change the version between two
releases (which only seem to happen three times per year). Ok, at the
moment I'm eagerly waiting for 1.81.0 because of some blockers that
have recently been fixed, but in general I don't care. So the issue is
not really "--depth 1" or incremental builds, but the missing logic in
FetchContent that keeps refetching everything every time I touch any
single CMakeLists.txt or do a simple rebase.

And I answered about "subset of libraries": I need 71 of them to cater
for two or three that I actually need, which completely defeats the
purpose of modular fetch.

> Whichever method is used, it should try to "play nice" and reuse as much
> as it can to avoid abusing cloud resources.  (And this also improves
> speed, so is good as a selfish goal too.)

I could easily reuse the tarball though, while reusing a git clone
seems problematic in many ways.

Thank you for the super fast responses,
    Mojca