Re: [lmi] [PATCH] Add script allowing to install any wxWidgets version from Git

[Greg Chicares]

On 2018-04-05 23:27, Vadim Zeitlin wrote:
> On Thu, 5 Apr 2018 22:19:02 +0000 Greg Chicares <address@hidden> wrote:

To paraphrase the discussion that led us here: lmi's install* makefiles
work if servers are unavailable, and even if there is no internet connection,
because they cache all downloads; so I dream of mirroring the wx repository
locally, with all its submodules. An earlier discussion led to:

| submodules, which will still have to be [slowly] cloned from GitHub,
| even if you already have them too

and later (in .gitmodules, changing URL for zlib to a relative path):

| "git clone --recursive" would use local mirror of zlib. But you'd
| still have to create c:\cache_for_lmi\zlib.git, instead of just cloning the
| existing c:\cache_for_lmi\wxWidgets\src\zlib. And this would also break
| "git clone --recursive" when cloning local mirror by default.

but we want a solution that isn't slow (for data already cached)
and doesn't break.

> GC> What I have in mind is possibly simpler, because we'll never push to
> GC> it: just a read-only local mirror that can easily be kept synchronized
> GC> with upstream, as a drop-in replacement for the github remote URL.
> 
>  Yes, I understand. Keeping mirror up to date is simple enough, this is
> basically what install_wx.sh currently does in its beginning, i.e. you just
> want to "fetch" and then "submodule update" periodically. The only problem
> is that this mirror can't be a bare repository, as is typical for mirrors,
> it must have a working directory in order to have submodules.
> 
>  Alternatively, you could also have N+1 bare repositories where N is the
> number of submodules and +1 is for the main wxWidgets super-repository.
> Then updating them would involve only running "git fetch" for each of them
> in a loop, which is probably even simpler.

At first I balked at this idea: why should I have N+1 packages when,
to my limited way of thinking because I really don't understand git
submodules, the wx super-repository is a single, indivisible, unitary
entity that I'd just like to copy?

But now, with only slightly more understanding of submodules, I think this
might actually be ideal. Apparently it's somewhat like this C++ model:

  class repo // representation of a project repository
    { void clone(); };
  repo wx_super[N] = {wx_repo, zlib_repo, ...};

and I want to do

  wx_super.clone(); // Can't work.

But this does work:

  for(auto i : wx_super) {i.clone();}

Or, more likely:

  class super_repo : repo
  {
  public:
    void clone_all()
      {*this->repo::clone(); for(auto i : submodules) {i.clone();}
  private:
    repo submodules[N] = {wx_repo, zlib_repo, ...};
  };

If that's more or less valid, then the crucial insight is that a
basic-repository with submodules isn't just a basic-repository:
it's a super-repository, which IS-A basic-repository that HAS-A
collection of basic-repositories.

Thus, setting up distinct *.git bare repositories...

>  And if you set up things like this, i.e. using bare repositories (which
> are, by convention, named with a .git suffix, i.e. you'd have wx.git,
> zlib.git, png.git, ...), then it would be simple enough to use URLs based
> on the main repository URL for submodules using relative paths as I wrote,
> i.e. use $wx_git_url/../$submodule.git for them.

...actually parallels the underlying structure, and amounts to
mirroring exactly what we need to mirror: it's "as simple as
possible, but not simpler".

> Should we do it like this?

If I've understood this correctly, then yes, please.