Re: [lmi] Should we update libxml and its kin?

[Vadim Zeitlin]

On Wed, 23 Feb 2022 20:18:47 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> I pose this question because a corporate-server rebuild says:
GC> 
GC> + cd /opt/lmi/src/lmi/third_party/libxslt
GC> + NOCONFIGURE=1 ./autogen.sh
GC> libtoolize: putting auxiliary files in '.'.
GC> libtoolize: copying file './ltmain.sh'
GC> libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
GC> libtoolize: and rerunning libtoolize and aclocal.
GC> libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
GC> configure.ac:123: warning: The macro `AC_HEADER_STDC' is obsolete.
GC> configure.ac:123: You should run autoupdate.
GC> ./lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from...
GC> configure.ac:123: the top level
GC> configure.ac:12: installing './compile'
GC> [...]
GC> libexslt/Makefile.am: installing './depcomp'
GC> tests/XSLTMark/Makefile.am:420: warning: user target 'html' defined here ...
GC> automake: ... overrides Automake target 'html' defined here
GC> tests/XSLTMark/Makefile.am:420: consider using html-local instead of html
GC> 
GC> My guess would be that
GC>  - this build is okay, as long as lmi's tests pass;
GC>  - the obvious next step would be to update the relevant
GC>    submodules, in the hope that the xmlsoft.org people
GC>    have already fixed this--in preference to messing
GC>    with their stuff ourselves; and
GC>  - we should probably update all submodules when we
GC>    update wx, which may be soon if the DPI stuff is
GC>    ready for us to test here.
GC> Alternatively, should we add a routine 'autoupdate'
GC> step to every autotoolized rebuild, given that we're
GC> always rebuilding whole libraries from a 'clean' state
GC> and always running 'autogen' anyway?

 I don't think it's a good idea to always run autoupdate, it's a pretty
dumb script and it could break things that would work without it. I guess
we could try running autoupdate and fall back on the original versions if
it doesn't work out, but it seems simpler to just run it manually once
every few years, commensurably with the usual autoconf update frequency.

 FWIW I think I've already fixed these warnings locally (or at least I
fixed some very similar ones) but didn't bother submitting this because it
didn't seem to be worth it. I'll look at it again and submit a PR fixing
them.

 Please let me know if I should _not_ do it,
VZ

pgp_RqZDu_SfR.pgp
Description: PGP signature