Re: [lmi] PATCH: Submodule changes

[Greg Chicares]

On 2020-10-09 12:53, Vadim Zeitlin wrote:
> 
>  As always, please let me know if you have any questions

Here are some incidental comments and questions, none of which is
important enough to distract us from the present goal of getting
all these changes applied. We can discuss them at leisure.

* posix_fhs.make:

-platform_gnome_xml_libraries := \
+platform_xml_libraries := \
+  $(shell xmlwrapp-config --libs) \
   -lexslt \
   $(shell xslt-config --libs) \
   $(shell xml2-config --libs) \

The unchanged '-lexslt' line seems incongruous. Do you happen to know
whether it's superfluous? I can look into it; I just thought you might
know off the top of your head.

* msw_common.make:

-platform_gnome_xml_libraries := \
+platform_xml_libraries := \
+  -lxsltwrapp \
+  -lxmlwrapp \
   -lexslt \
   -lxslt \
   -lxml2 \

Here, I wonder whether the "$(shell libfoo-config --libs)" technique
would work for msw builds as well, so that this file could be made
to look more like 'posix_fhs.make'. I'd like to try the experiment,
but please let me know if you see some reason for this to be left
the way it is.

* objects.make:

 # These object files are used in both an application and a shared
 # library that it links to, only for builds that use shared-library
 # 'attributes'. This workaround is used merely because we don't yet
 # build these objects as a library. TODO ?? The duplication is not
 # correct: it validates linking, but the linked applications don't
 # run correctly.

 ifneq (,$(USE_SO_ATTRIBUTES))
-  duplicated_objects = $(boost_filesystem_objects) $(xmlwrapp_objects)
+  duplicated_objects = $(boost_filesystem_objects)
 endif

I'm really glad that half of this problem is now solved (and the other
half will be solved soon, so that this defect can be eradicated).

* install_wxpdfdoc.sh

-cd "$proxy_wxpdfdoc_dir"
+cd "$wxpdfdoc_dir"
 autoreconf --verbose

Just wondering--is there a reason why autoreconf is not run by
the related 'install_wx.sh'?

* 
https://github.com/vadz/lmi/pull/162/commits/be12e2e2621189d0d90a3387cfd4c807b8b0dc68

"Consistently use the same config.guess in all build scripts"

Later, I'll want to look for all other uses of 'config.guess'.
I remember wrestling with this problem and choosing something like
  $(/usr/share/libtool/build-aux/config.guess)
elsewhere because it seemed like the least bad way, even though
it's debian-specific (but that's because GNU/Linux distros can't
seem to agree on a common location for this crucial script).
For building libraries, I had thought it would be better to use
the exact version each library provides; that seemed like a
compelling reason to me--so it's interesting to read that Ilya
found an oddity in the one wxPdfDoc provides, because now I see
my original reasoning as something other than conclusive.