Re: [lmi] wx-msw vs. wx-gtk sonames

[Vadim Zeitlin]

On Thu, 25 Mar 2021 19:21:08 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> Vadim--Names of installed wx libraries differ greatly between
GC> msw and gtk. For msw, we can tell the wx SHA1 from the library
GC> name. For gtk, we can't, which seems less good. Demonstration:

 Yes, as you have correctly surmised, vendor support is MSW-only. In fact:

        % ./configure --help|grep vendor
          --enable-vendor=VENDOR  vendor name (win32 DLL only)

GC> and wx is configured with:
GC>   --enable-vendor=$vendor
GC> so this seems to be an inconsistency in wx's own build system.
GC> However, I conjecture that $vendor is the red-headed stepchild
GC> of wx configuration

 Indeed. FWIW I don't know why had it been originally added (this was a
very long time ago) and I've never used it personally.

 One of the problems I have with it is that it applies to the wx DLL only,
i.e. in lmi case none of the other DLLs has it, even if wxpdfdoc is just as
affected by any changes to wx as the main DLL itself. I.e. I absolutely
agree that it's useful to have the information about the wx build available
in some path name, but I just think it's present at the wrong level
currently and it should rather be in the path of some directory instead.
And as we already use LMI_COMPILER in the /opt/lmi/local subdirectory name
that we use, why not include the compiler version and all the extra stuff
into this directory name as well?

 BTW, here is what I use as the cache key in the CI builds (broken down
into several lines for readability):

build-${{ env.LMI_COMPILER }}-${{ env.gcc_version }}-${{ env.LMI_TRIPLET }}
-${{ hashFiles('install_xml_libraries.sh', 'install_wx.sh', 
'install_wxpdfdoc.sh') }}
-${{ env.xml2_sha1 }}-${{ env.xmlwrapp_sha1 }}-${{ env.xslt_sha1 }}
-${{ env.wx_sha1 }}-${{ env.wxpdfdoc_sha1 }}

We don't need the hashes of the install*.sh scripts, of course, and could
just use lmi SHA1 itself instead, but if we appended (or XOR'd together,
maybe, to make this less long) all the other SHA1s to the directory name,
this would uniquely identify all the DLLs inside it, not just the wx one.

GC> ...so, if I want to add 'x86_64-pc-linux-gnu-10.0-c9486f9c'
GC> into the soname, is there a better way than using $vendor?

 Right now there is no way at all to do it under Unix. We probably could
make vendor string part of soname there, although we definitely wouldn't
want to make it "_custom" by default as under MSW. This doesn't seem like
an especially useful feature to me, but OTOH I don't see any real harm in
it neither, and it would at least eliminate the difference in behaviour
between MSW and the other platforms.

 One problem I see is to understand how is this going to work with
wx-config matching algorithm, i.e. whether we need to add a new
--vendor=xxx option to it or if we can just ignore vendor when matching.
I.e. it's not going be completely trivial, just because nothing related to
wx-config ever is, but should be doable, of course.

 Please let me know if I should try to do it, or if you might be open to
discussing the suggestion above, i.e. getting rid of the vendor entirely
and using a similar string as part of the directory, rather than file,
name.

 Thanks,
VZ

pgptwcJfvZnUs.pgp
Description: PGP signature