Re: [lmi] PATCH: Submodule changes

[Vadim Zeitlin]

On Fri, 9 Oct 2020 15:46:20 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

GC> On 2020-10-09 12:53, Vadim Zeitlin wrote:
GC> > 
GC> >  As always, please let me know if you have any questions
GC> 
GC> Here are some incidental comments and questions, none of which is
GC> important enough to distract us from the present goal of getting
GC> all these changes applied. We can discuss them at leisure.
GC> 
GC> * posix_fhs.make:
GC> 
GC> -platform_gnome_xml_libraries := \
GC> +platform_xml_libraries := \
GC> +  $(shell xmlwrapp-config --libs) \
GC>    -lexslt \
GC>    $(shell xslt-config --libs) \
GC>    $(shell xml2-config --libs) \
GC> 
GC> The unchanged '-lexslt' line seems incongruous. Do you happen to know
GC> whether it's superfluous? I can look into it; I just thought you might
GC> know off the top of your head.

 Strangely enough, I don't think it's superfluous, i.e. xslt-config
behaviour doesn't seem to have changed since the post from October 2001
linked from a comment just above: it still doesn't output -lexslt.

 When using shared libraries -- as we always do right now -- it is,
however, superfluous, together with the call to xslt-config itself as well
as xml2-config, because `xmlwrapp-config --libs` already output everything
they do. But this wouldn't be the case with static libraries and I wasn't
100% sure we'd never want to do it, so I preferred to err on the side of
caution. After all having an extra "-lexslt" doesn't do any harm, while not
having it could do it.

GC> * msw_common.make:
GC> 
GC> -platform_gnome_xml_libraries := \
GC> +platform_xml_libraries := \
GC> +  -lxsltwrapp \
GC> +  -lxmlwrapp \
GC>    -lexslt \
GC>    -lxslt \
GC>    -lxml2 \
GC> 
GC> Here, I wonder whether the "$(shell libfoo-config --libs)" technique
GC> would work for msw builds as well, so that this file could be made
GC> to look more like 'posix_fhs.make'. I'd like to try the experiment,
GC> but please let me know if you see some reason for this to be left
GC> the way it is.

 No, I've only done it like this for consistency. It's true that we could
use the same expression in both places (or maybe do it in a single place in
configuration.make itself?) because we rely on working shell on all
platforms anyhow.

GC> * install_wxpdfdoc.sh
GC> 
GC> -cd "$proxy_wxpdfdoc_dir"
GC> +cd "$wxpdfdoc_dir"
GC>  autoreconf --verbose
GC> 
GC> Just wondering--is there a reason why autoreconf is not run by
GC> the related 'install_wx.sh'?

 For historical reason wxWidgets contains all the files generated by
autoreconf in the repository, so running it is not necessary for it.
Moreover, it doesn't even work out of the box right now and even if it did,
running it would still results in changes in the working copy of the
repository because it would change these generated files which are present
in it. So the simplest solution by far is to just not do it, at least
unless wxWidgets removes these generated files (but there are no plans to
do it anytime soon).
 
GC> * 
https://github.com/vadz/lmi/pull/162/commits/be12e2e2621189d0d90a3387cfd4c807b8b0dc68
GC> 
GC> "Consistently use the same config.guess in all build scripts"
GC> 
GC> Later, I'll want to look for all other uses of 'config.guess'.
GC> I remember wrestling with this problem and choosing something like
GC>   $(/usr/share/libtool/build-aux/config.guess)
GC> elsewhere because it seemed like the least bad way,

 I think we've discussed it and I thought /usr/share/misc/config.guess
might be a better choice on a Debian system, but it's probably also a less
portable one. The most logical choice would be to use the copy included in
automake, but on Debian systems this copy is, unfortunately, versioned,
i.e. the file is something like /usr/share/automake-1.16/config.guess
(there is also /usr/share/automake/config.guess but it belongs to an
awfully old automake1.4 package and it wouldn't be a good idea to use it).

 Anyhow, I agree that /usr/share/libtool/build-aux/config.guess is a very
reasonable choice. But beyond this, I think it's important to use the same
version everywhere.

GC> even though
GC> it's debian-specific (but that's because GNU/Linux distros can't
GC> seem to agree on a common location for this crucial script).

 Probably because each package is supposed to come with its own version. So
the traditional solution to this problem would probably be to just include
the (ideally latest version of the) script in lmi itself.

GC> For building libraries, I had thought it would be better to use
GC> the exact version each library provides; that seemed like a
GC> compelling reason to me--so it's interesting to read that Ilya
GC> found an oddity in the one wxPdfDoc provides, because now I see
GC> my original reasoning as something other than conclusive.

 The problem Ilya ran into is not really due to config.guess, wxPdfDoc
could have .gitattributes file setting eol=lf for this file just as
wxWidgets does (and, in fact, I should probably make a PR to it even if we
don't use its config.sub any longer). But I've decided to fix it in this
way because I believe the same script should be used for everything:
imagine that wxPdfDoc updates its config.guess to the latest version which
now starts returning i686-w64-maxgw instead of -mingw. This would make it
incompatible with wxWidgets, which is notoriously bad at keeping things up
to date and create problems during the build.

 Of course, chances of an existing platform being renamed like this are
slim. But it's conceivable that some new platform might become being
recognized by a later version of the script when older ones just returned
some generic name for it -- and this did happen in the past. So using the
same version of the script is really more robust.


 Summary: I don't think there is anything to do here urgently right now,
but I could make the suggested changes to msw_common.make slightly later.
Please let me know if I should.

 Thanks,
VZ

pgphtg7DdXlTx.pgp
Description: PGP signature