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

[Greg Chicares]

On 2020-10-02 16:37, Vadim Zeitlin wrote:
> On Fri, 2 Oct 2020 16:22:11 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> That's okay--it's exactly what I asked for, because I've been
> GC> running these tests so often lately that it's easy to select
> GC> the right commands from shell history. And I have encountered
> GC> an error:
> GC> 
> GC> In file included from /opt/lmi/src/lmi/xml_xslt_wrapp.cpp:39:
> GC> /opt/lmi/third_party/src/libxml/event_parser.cxx:61:38: error: 
> conflicting declaration of C functio
> GC> n ‘void xmlSAX2InitDefaultSAXHandler(xmlSAXHandlerV1*, int)’
> GC>    61 |     #define initxmlDefaultSAXHandler xmlSAX2InitDefaultSAXHandler
> GC>       |                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
> GC> /opt/lmi/local/include/libxml2/libxml/SAX2.h:159:3: note: previous 
> declaration ‘void xmlSAX2InitDef
> GC> aultSAXHandler(xmlSAXHandler*, int)’
[...]
> so I'm already looking into it. I don't understand what is the problem just
> yet, but I'll find and fix it a.s.a.p.

No rush. My guess is that this calls for an xmlwrapp upgrade,
and instead of using some lmi makefile for that, I'd rather
just wait for the xmlwrapp submodule. Getting all of that
a week from now is better for me than getting an incremental
fix now.

>  And we're going to push forward the work on adding running the tests to
> the CI builds (at least for MSW for now, although ideally I'd like to run
> them under Linux too later) because it's embarrassing that I've managed to
> push out a change which doesn't even compile, this hasn't happened to me
> since literally years (by a weird coincidence, just about since when CI
> integration become widespread and convenient), sorry.

Eto ya vinovat--I asked you to push out a specific update for me
to test--so it's no reflection on your work.

> GC> > GC> Would we be better off doing something more like
> GC> > GC> what lmi's install_wx scripts do, i.e., fetch everything
> GC> > GC> that's available, but then use a checkout as of some fixed
> GC> > GC> SHA1 that's specified in the script?
> GC> > 
> GC> >  This is exactly how it works, except we don't need to do anything, Git
> GC> > does it for us. From Git point of view, .gitmodules records the path to 
> the
> GC> > repository, while the actual commit (see e.g. PR 154 above) records the
> GC> > SHA-1 of the revision of that repository which should be used. So it's
> GC> > completely self-contained and stable, i.e. doesn't change unless we
> GC> > explicitly commit the change to lmi.

Here's what I've done locally for the short term:

/opt/lmi/src/lmi[0]$git --no-pager log -1 --oneline --patch third_party/libxml2 
56763342 (HEAD -> master, origin/master, origin/HEAD) Switch to using latest 
version of libxml2
diff --git a/third_party/libxml2 b/third_party/libxml2
index bdec2183..0b3c64d9 160000
--- a/third_party/libxml2
+++ b/third_party/libxml2
@@ -1 +1 @@
-Subproject commit bdec2183f34b37ee89ae1d330c6ad2bb4d76605f
+Subproject commit 0b3c64d9f2f3e9ce1a98d8f19ee7a763c87e27d5

/opt/lmi/src/lmi[0]$pushd third_party/libxml2                    
/opt/lmi/src/lmi/third_party/libxml2 /opt/lmi/src/lmi
/opt/lmi/src/lmi/third_party/libxml2[0]$git rev-parse --quiet --verify 
"bdec2183f34b37ee89ae1d330c6ad2bb4d76605f^{commit}"
bdec2183f34b37ee89ae1d330c6ad2bb4d76605f
/opt/lmi/src/lmi/third_party/libxml2[0]$git checkout 
bdec2183f34b37ee89ae1d330c6ad2bb4d76605f     
Previous HEAD position was 0b3c64d9 Handle dumps of corrupted documents more 
gracefully
HEAD is now at bdec2183 Release of libxml2-2.9.4
/opt/lmi/src/lmi/third_party/libxml2[0]$popd
/opt/lmi/src/lmi

/opt/lmi/src/lmi[0]$git --no-pager diff 
diff --git a/third_party/libxml2 b/third_party/libxml2
index 0b3c64d9..bdec2183 160000
--- a/third_party/libxml2
+++ b/third_party/libxml2
@@ -1 +1 @@
-Subproject commit 0b3c64d9f2f3e9ce1a98d8f19ee7a763c87e27d5
+Subproject commit bdec2183f34b37ee89ae1d330c6ad2bb4d76605f-dirty

> and then this is just another commit, as any other one, i.e. you can/should
> push it to the remote. The only difficulty here is that other people must
> be able to get the submodule commit referenced by the main repository when
> they pull your changes, so you need to think about also pushing the
> submodule, otherwise you may break things for them.

I adapted the 'git rev-parse --quiet --verify' command above
from 'install_wx.sh' to guard against that difficulty. Because
I've only gone back in time, and verified it first, I gather
that I could push this safely (I have no power today to harm
the github repository anyway), but I'm not sure this brand-new
chroot has my savannah credentials yet.