On 2021-01-31 Markus Rickert wrote:
> I noticed however, that there is still an issue when building against
> a library that was built against liblzma due to using ALIAS (e.g.,
> testproject -> LibXml2 -> LibLZMA):
> CMake will resolve the alias to include "liblzma::liblzma" instead of
> "LibLZMA::LibLZMA" in the LibXml2 link dependencies. When another
> library does not set CMAKE_FIND_PACKAGE_PREFER_CONFIG, it will
> however still use FindLibLZMA and is then not able to resolve the
> "liblzma::liblzma" dependency.
>
> With the following alternative (that is also used in the CMake
> exported target files), LibXml2 will continue to use
> "LibLZMA::LibLZMA" in its dependencies when linking against this
> target:
> add_library(LibLZMA::LibLZMA INTERFACE IMPORTED)
> set_target_properties(LibLZMA::LibLZMA PROPERTIES
> INTERFACE_LINK_LIBRARIES liblzma::liblzma)
I'm afraid I didn't I fully understand the exact situation when this
problem occurs. I trust that it's real and that you tested it, thus
I committed this change. Thanks! I assume it has no significant
downsides compared to the ALIAS method.
Can something go wrong in the opposite direction: CMakeLists.txt
recommends that one uses "find_package(liblzma 5.2.5 REQUIRED CONFIG)"
to ensure that FindLibLZMA isn't used. If one does so and then
something else in the project uses FindLibLZMA anyway, does the
interface library (or previously the alias) cause a problem? Or is this
situation unlikely to happen?
> > - FindLibLZMA sets a few CMake cache variables that the config
> > file doesn't, for example, LIBLZMA_HAS_EASY_ENCODER. I have no
> > idea if there are packages that care about this.
>
> This seems to be due to the autotools options for enabling/disabling
> certain encoders and decoders. If there is no equivalent CMake option
> for modifying this you could add variables to the config files that
> are always set to ON:
> set(LIBLZMA_HAS_AUTO_DECODER ON)
> set(LIBLZMA_HAS_EASY_ENCODER ON)
> set(LIBLZMA_HAS_LZMA_PRESET ON)
Autotools options being the reason sounds reasonable, although all
normal builds of liblzma always have all features enabled. However, I
might add CMake options to disable encoder or decoder because there are
use cases where encoder support isn't needed. Then those compatibility
variables would need to be set conditionally too.
If liblzma is built with some features disabled and then something
breaks, I'm not sure if I should care. With Autotools-based builds
no help is provided: if one wants to disable features to reduce the
library size, one must be careful to do it without breaking anything.
In the CMake world, perhaps it could matter when two things are able to
use liblzma but only one of them needs encoding support. Then those
variables could help to keep the build working. However, it wouldn't
suprise me if most packages don't check those variables and simply
assume that all features are available if liblzma is found (which I
think is reasonable behavior). I didn't try to verify this though so I
may be wrong.
> The entries for LIBLZMA_VERSION_MAJOR etc. can also be easily added
> to the file:
> set(LIBLZMA_VERSION_MAJOR ${PROJECT_VERSION_MAJOR})
> set(LIBLZMA_VERSION_MINOR ${PROJECT_VERSION_MINOR})
> set(LIBLZMA_VERSION_PATCH ${PROJECT_VERSION_PATCH})
> set(LIBLZMA_VERSION_STRING \"${PROJECT_VERSION}\")
This can be done too, although first it should be decided if full
compatibility with FindLibLZMA is desirable. I guess FindLibLZMA won't
see major changes so maintaining compatibility wouldn't need frequent
changes in the liblzma config file.
FindLibLZMA also sets LIBLZMA_LIBRARIES and LIBLZMA_INCLUDE_DIRS. Is it
OK to not care about these in context of FindLibLZMA compatibility?
> > Perhaps there are other details affecting compatiblity. I just
> > wonder how big mistake it was to use liblzma::liblzma in the config
> > file. I guess it's too late to change it now.
>
> By using the same principle as above, you should still be able to
> change this if you prefer. In that case, liblzma::liblzma can be an
> alias for LibLZMA::LibLZMA in the config file.
I was thinking if the naming should have been such that it doesn't
overlap or conflict with FindLibLZMA module at all. However, that would
mean that if one thing depends on, for example, xz_liblzma::xz_liblzma
and another thing on LibLZMA::LibLZMA, then two different targets would
refer to the same library and so the compiler and linker flags would be
duplicated. I'm not sure if that could become a problem.
I have always written liblzma in lower case so changing the primary
target name to LibLZMA::LibLZMA would look a bit funny to me. Of
course, I'm fine with it still if it means that things work better
overall.
> I think the CMake build files also were not yet included in any
> official release.
CMakeLists.txt and friends were included in XZ Utils 5.2.5 (with the
bug that shared library doesn't build on Windows). It's described as
experimental so in that sense it could be OK to change things.
> You can add an alias for target "liblzma" to target "LibLZMA" in the
> CMakeLists.txt file (after the target definition in add_library, line
> 193) for users that embed the xz project as a subdirectory:
> add_library(LibLZMA::LibLZMA ALIAS LibLZMA)
> add_library(liblzma ALIAS LibLZMA::LibLZMA)
> add_library(liblzma::liblzma ALIAS LibLZMA::LibLZMA)
If I change the main add_library(liblzma <files>) to add_library(LibLZMA
<files>) then the filename will be LibLZMA.something too. That isn't
good because then one cannot replace a CMake-built shared liblzma with
an Autotools-built one on operating systems where file and library
names are case sensitive.
--
Lasse Collin | IRC: Larhzu @ IRCnet & Freenode
