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

[Greg Chicares]

On 2020-10-02 14:09, Vadim Zeitlin wrote:
> On Fri, 2 Oct 2020 13:41:22 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> Okay, let's try master, and adopt it unless we find a severe
> GC> regression. If you would please update the github site, I'll
> GC> test lmi with libxml2 master--I have the knowledge and hardware
> GC> to do an acceptance test without much conscious thought, in the
> GC> background, while I work on other things. And I create new
> GC> chroots as freely as you create git branches, because those
> GC> things cost nothing from our respective points of view.
> 
>  Thanks, I've created https://github.com/vadz/lmi/pull/154 now, which
> contains a single commit c5f0f3600b2df631ea5199e46af90f0dd51c953e updating
> just the submodule. I haven't yet had time to test it at all though,

That's okay--it's exactly what I asked for, because I've been
running these tests so often lately that it's easy to select
the right commands from shell history. And I have encountered
an error:

In file included from /opt/lmi/src/lmi/xml_xslt_wrapp.cpp:39:
/opt/lmi/third_party/src/libxml/event_parser.cxx:61:38: error: conflicting 
declaration of C functio
n ‘void xmlSAX2InitDefaultSAXHandler(xmlSAXHandlerV1*, int)’
   61 |     #define initxmlDefaultSAXHandler xmlSAX2InitDefaultSAXHandler
      |                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /opt/lmi/local/include/libxml2/libxml/globals.h:20,
                 from /opt/lmi/local/include/libxml2/libxml/threads.h:35,
                 from /opt/lmi/local/include/libxml2/libxml/xmlmemory.h:218,
                 from /opt/lmi/local/include/libxml2/libxml/tree.h:1307,
                 from /opt/lmi/third_party/src/libxml/ait_impl.h:42,
                 from /opt/lmi/third_party/src/libxml/ait_impl.cxx:34,
                 from /opt/lmi/src/lmi/xml_xslt_wrapp.cpp:34:
/opt/lmi/local/include/libxml2/libxml/SAX2.h:159:3: note: previous declaration 
‘void xmlSAX2InitDef
aultSAXHandler(xmlSAXHandler*, int)’
  159 |   xmlSAX2InitDefaultSAXHandler    (xmlSAXHandler *hdlr,
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
make[1]: *** [/opt/lmi/src/lmi/workhorse.make:928: xml_xslt_wrapp.o] Error 1

Looks like a deprecated version-1 handler. Perhaps you're already on top
of that and we just need a concurrent xmlwrapp upgrade, so I won't look
into it further right now unless you can't easily reproduce it.

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

What file would I change? Sorry for yet another naive question, but
I look at
  https://github.com/vadz/lmi/compare/latest-libxml2
and see
  Showing 1 changed file with 1 addition and 1 deletion.
but that file is 'third_party/libxml2', which AIUI should not be
edited manually; and
  Submodule libxml2 updated 966 files
so should I change one of those hundreds of files, e.g.
  .git/modules/third_party/libxml2/HEAD
?

> GC> One more question--is there a reasonable way to make the
> GC> submodule directories reside somewhere else? I've found
> GC> it convenient to run commands like
> GC>   grep -r '/bin/sh' * |less
> 
>  You should use "git grep" instead.

That's truly useful. If I'd ever known about it, I had forgotten. Thanks.

>  Yes, all repository contents must reside inside the repository. In fact
> you _could_ trick Git by making third_party/foo symlinks to whenever you
> want them to reside and then hiding the change from Git using update-index
> --skip-worktree, and I do it to avoid having a zillion copies of wx
> submodule on my system(s), but I strongly recommend _against_ doing this,
> at least initially, because submodules can be tricky to get used to work
> with without any dirty hacks on top of them.

Okay, I certainly won't try that, at least not this year.