[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.
Re: [lmi] PATCH: Submodule changes, Greg Chicares, 2020/10/09