lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] PATCH: Submodule changes


From: Greg Chicares
Subject: Re: [lmi] PATCH: Submodule changes
Date: Tue, 13 Oct 2020 00:32:32 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

On 2020-10-09 16:14, Vadim Zeitlin wrote:
> On Fri, 9 Oct 2020 15:46:20 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
[...]
> 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.

Does xsltwrapp actually use anything provided by '-lexslt',
or does it depend only on the functionality '-lxslt' provides?
I'm not sure whether the "many EXSLT extension functions" here:

http://exslt.org/
| 17/10/2001 Daniel Veillard's libXSLT XSLT processor now implements
| many EXSLT extension functions thanks to Thomas Broyer implementation.

have been folded into '-lxslt', or provided only by '-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.

Static libraries: agreed, "never say never".

> 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.

Yes, that sounds like a good idea.

> 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.

/usr/share/misc/ would seem to be the right place according to
  https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html
and, on my debian system at least, it's the referent of the
libtool/build-aux symlink:

$ls -l /usr/share/libtool/build-aux/config.guess /usr/share/misc/config.guess
lrwxrwxrwx 1 root root    23 Aug 28  2019 
/usr/share/libtool/build-aux/config.guess -> ../../misc/config.guess
-rwxr-xr-x 1 root root 44283 Feb 24  2018 /usr/share/misc/config.guess

so I went ahead and changed it everywhere in commit 1f4ed3ccf5.

>  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.

Actually, it's probably easier for me to do it: the change is
trivial, while testing it on an ever-changing corporate server
is the part that takes time--but I'm already trying to get that
server to work again, so it's a good time to make little changes.
My only question is whether 'libexslt' is even wanted.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]