Re: [lmi] [PATCH] Use submodules for, and newer versions of, libxml2 and libxslt

[Greg Chicares]

On 2020-10-02 12:22, Vadim Zeitlin wrote:
> On Fri, 2 Oct 2020 12:06:16 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:

[...speaking of libxml2...]

> GC> The latest official release is 41a34e1f:
> GC>   https://gitlab.gnome.org/GNOME/libxml2/-/tags/v2.9.10
> 
>  Speaking of this, I don't know if we should use v2.9.10 or master. I see
> quite a few post-2.9.10 commits that seem to be worth including, just have
> a look at
> 
>       $ git log --oneline --reverse v2.9.10..master | grep " Fix"
> 
> for a few of them, purporting to fix crashes, memory leaks, catastrophic
> slowdowns (due to quadratic complexity) etc. I think they're going to
> release v2.9.11 soon, because 2.9.10 was almost a year ago and, unlike some
> other projects, they do seem to release regularly, but we can't wait for it
> if we want to do this now. And then I think using master is better. BTW,
> notice that we don't use an official release of libxslt neither, because it
> doesn't include a fix required for building it with MinGW 10.1, so it
> wouldn't be surprising or inconsistent to use the current master of libxml2
> too.

Okay, let's try master, and adopt it unless we find a severe
regression. If you would please update the github site, I'll
test lmi with libxml2 master--I have the knowledge and hardware
to do an acceptance test without much conscious thought, in the
background, while I work on other things. And I create new
chroots as freely as you create git branches, because those
things cost nothing from our respective points of view.

BTW, what exactly does it mean to use libxml2 master? It
must be the SHA1 that is HEAD at some moment, but when does
that SHA1 change? Does it change whenever libxml2 is pulled
to github? Would we be better off doing something more like
what lmi's install_wx scripts do, i.e., fetch everything
that's available, but then use a checkout as of some fixed
SHA1 that's specified in the script? That way, github would
make everything available whenever you pull it, and the lmi
sources could independently move the SHA1 forward or backward,
or keep it static.

> GC> ...yes, please do update libxml2.
> 
>  I will do it soon but, just for the reference, the way it works is just
> that you update the lmi branch in the submodule (in whichever way you see
> fit, i.e. by fast-forwarding it to v2.9.10 tag, merging with master,
> whatever), then pushing submodule to its origin (which, as I'm belatedly
> realizing, you can't do without a GitHub account...)

Setting up a github account at this moment would just push
one more task onto my stack, taking time away from other
needful work that I already can't spend time on because
that stack's too deep. You might say it's as simple as
learning to work with git submodules, and even simpler than
learning about git merges, but my stack has overflowed and
push() throws an ENOTIME exception.

>  But, anyhow, as I said, I'll do it, especially because you can't do it
> anyhow, sorry for forgetting about it! Just please let me know if you
> object to using libxml2 master and would rather stick to v2.9.10.

Let's try master. The other submodule-related improvements
seem much less risky to me: we'll be getting
 - the same versions of wx{W,P}* we're using now, by other
   means, but the only thing that can go wrong is the new
   mechanism (the container, not the contents, if you will)
   and that's something we'll notice quickly and be able
   to fix;
 - probably the latest versions of x*wrapp, but that's a
   small library under your control, and I don't think
   lmi has ever been affected by a regression therein;
but I'd be less astonished if we find a problem with
libxml2 master.

One more question--is there a reasonable way to make the
submodule directories reside somewhere else? I've found
it convenient to run commands like
  grep -r '/bin/sh' * |less
which until now have conveniently looked in
  lmi/src
  lmi/src/gwc
  lmi/src/tools
but not in gobs of submodules. If they could live in
  lmi/src/../third_party
then I'd regain that convenience. But would that violate
some precondition that git assumes?