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

[Vadim Zeitlin]

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> In file included from /opt/lmi/local/include/libxml2/libxml/globals.h:20,
GC>                  from /opt/lmi/local/include/libxml2/libxml/threads.h:35,
GC>                  from /opt/lmi/local/include/libxml2/libxml/xmlmemory.h:218,
GC>                  from /opt/lmi/local/include/libxml2/libxml/tree.h:1307,
GC>                  from /opt/lmi/third_party/src/libxml/ait_impl.h:42,
GC>                  from /opt/lmi/third_party/src/libxml/ait_impl.cxx:34,
GC>                  from /opt/lmi/src/lmi/xml_xslt_wrapp.cpp:34:
GC> /opt/lmi/local/include/libxml2/libxml/SAX2.h:159:3: note: previous 
declaration ‘void xmlSAX2InitDef
GC> aultSAXHandler(xmlSAXHandler*, int)’
GC>   159 |   xmlSAX2InitDefaultSAXHandler    (xmlSAXHandler *hdlr,
GC>       |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
GC> make[1]: *** [/opt/lmi/src/lmi/workhorse.make:928: xml_xslt_wrapp.o] Error 1
GC> 
GC> Looks like a deprecated version-1 handler. Perhaps you're already on top
GC> of that and we just need a concurrent xmlwrapp upgrade, so I won't look
GC> into it further right now unless you can't easily reproduce it.

 I just wanted to say that I can't reproduce this under Linux for some
reason, but I do see it the CI builds at

        https://github.com/thesiv/lmi/pull/6/checks#step:13:33

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.

 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.

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.
GC> 
GC> What file would I change?

 The "file" is third_party/libxml2 itself. I.e. you change the version of
the libxml2 sources used. Of course, it's not really a "file" because its
"contents" is something like

        Subproject commit 0b3c64d9f2f3e9ce1a98d8f19ee7a763c87e27d5

(use "git log -p third_party/libxml2" to see this). And you change this
"file" by changing the commit in the sub-repository (and you can use "git
diff" to see that). But it's important to realize that you still change the
main repository by staging the submodule path (with git-add) and
committing, as with any other file.

 I.e. in the simplest case, after updating the submodule to contain what
you want it to contain (e.g. fast-forwarding it to v2.9.11 libxml2 release
when it's done, in the simplest case), you just go to the main repository
and do

$ git commit -m 'Update libxml2 submodule to v2.9.11' third_party/libxml2

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.

 Please let me know if you have any other questions,
VZ

pgpyuGUf_Ilj5.pgp
Description: PGP signature