I'm not a xz developer, but more of a user, I hope these can be of use to

- Although you mark your cmake minimum as 3.1, your project command
contains `DESCRIPTION`, and `HOMPAGE_URL`, both of which are not provided
in cmake 3.1 https://cmake.org/cmake/help/v3.1/command/project.html I did
not check for any other incompatibilities.
- The ${CMAKE_CURRENT_LIST_DIR} in your add_library are a bit
unnecessary since any non-full paths are already assumed to be relative for
- The lib prefix in the target generated by the add_library command is not
needed as cmake will automatically prepend lib on appropriate targets, if
you want to force it to always output as `liblzma` you could use
https://cmake.org/cmake/help/v3.0/variable/CMAKE_SHARED_LIBRARY_PREFIX.html and
set them to "lib" or set the prefix in line 269 instead of blank
- for line 214 when building with `cmake ${XZ_SOURCE}
CMake Warning (dev) at CMakeLists.txt:42 (add_library):
  Policy CMP0063 is not set: Honor visibility properties for all target
  types.  Run "cmake --help-policy CMP0063" for policy details.  Use the
  cmake_policy command to set the policy and suppress this warning.

  Target "liblzma" of type "STATIC_LIBRARY" has the following visibility
  properties set for C:


  For compatibility CMake is not honoring them for this target.
This warning is for project developers.  Use -Wno-dev to suppress it.
You can ignore it without any problems, it just may look ugly for an
end-user trying to compile using cmake
 - I'm not sure if `-Wl,--version-script` is supported on all OSs. I think
AppleClang doesn't, but it's probably fine to wait until a macOS user can
provide info or not

On Sun, Feb 16, 2020 at 11:12 AM Lasse Collin <lasse.col...@tukaani.org>

> On 2020-02-15 Mario Emmenlauer wrote:
> > This has been my foremost reason for cmake. While not everything is
> > perfect, it has proven to work very well for generating native build
> > instructions with well defined settings on quite a number of
> > platforms.
> CMake can be used like GNU Autotools to make portable builds but in this
> case it's not practical to move the whole project to CMake. It should
> be enough to have something that does as little as possible to produce
> usable output for MSVC and ignore the portability features of CMake...
> > I would start with the instructions from vcpkg (see
> > https://github.com/microsoft/vcpkg/tree/master/ports/liblzma) but
> > unify their multiple patches into a single, concise CMakeLists.txt.
> ...and these files seem to do that, and they only build liblzma. Thanks!
> There are several details that I don't understand (yet). I see some
> small minor problems though. liblzma_w32res.rc is missing from from
> Windows DLL output. The "NOT WIN32" part looks a bit broken even though
> it might compile. For example:
>   - The definition of SIZEOF_SIZE_T is wrong as it's not understandable
>     by the preprocessor but it's often not needed either so a compiler
>     may not care.
>   - Some #defines are missing that are needed for a good build on
>     GNU/Linux.
> I wonder why enable-uwp-builds.patch is needed. Is GetModuleHandle a
> problem on UWP? If so, it can be changed to make things simpler.
> Compatibility with Windows 98 isn't that important... ;-)
> Since I would be maintaining the CMakeLists.txt file, I thought I should
> understand it too. After reading some CMake docs and the linked vcpkg
> files I ended up with the attached file. It does a little more than
> just MSVC support so I can test it on GNU/Linux too. It only works
> against xz.git, but if this can be finished quickly, a version can be
> included in the upcoming XZ Utils 5.2.5.
> Some known issues with my CMakeLists.txt:
>   - The Windows parts aren't tested at all. The file header says
>     32/64-bit x86/ARM but I tried only x86-64 GNU/Linux.
>   - It obviously doesn't attempt to be properly portable since it
>     assumes little endian etc. but that isn't the goal for now either.
>   - I don't have much clue about the generated .cmake files. E.g.
>     is the single-line liblzmaConfig.cmake fine or does it need
>     something extra to handle the dependency on Threads::Theads?
>   - The default installation paths come from GNUInstallDirs.
>     The .cmake files are installed into a different directory
>     than in the vcpkg files.
>   - All #defines are passed as command line arguments. That is, it
>     doesn't create or use config.h. The number of #defines isn't
>     huge so it the command line lengths don't get too long, but
>     is it bad/ugly on Windows?
>   - NDEBUG shouldn't be #defined for debug builds.
> Thoughts, fixes, suggestions etc. are welcome.
> --
> Lasse Collin  |  IRC: Larhzu @ IRCnet & Freenode

Reply via email to