I'm not a xz developer, but more of a user, I hope these can be of use to you
- 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 add_library. - 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.1/variable/CMAKE_STATIC_LIBRARY_PREFIX.html or 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} -DBUILD_SHARED_LIBS=OFF -DCMAKE_BUILD_TYPE=Debug` ``` 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: C_VISIBILITY_PRESET For compatibility CMake is not honoring them for this target. This warning is for project developers. Use -Wno-dev to suppress it. ``` https://cmake.org/cmake/help/v3.3/policy/CMP0063.html 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> wrote: > 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 >
