On 2020-02-16 Christopher Degawa wrote: > > but I don't have much clue how old CMake should be supported. > > > If you don't care about centos 7 using 2.8.12, 3.5 is a good lower > end to start with since that's what ubuntu 16.04 has in their default > repository. Any higher and you might find llvm-dev's discussion of > updating the cmake requirements to 3.15 of interest > http://lists.llvm.org/pipermail/llvm-dev/2019-October/136295.html > > (Centos 8 has 3.11 it seems, nice)
Thanks! I will keep those version numbers in mind. I guess the importance of supporting old versions largely depends on if the CMake support will become usable for more than building liblzma on Windows. > On Sun, Feb 16, 2020 at 4:48 PM Lasse Collin > <lasse.col...@tukaani.org> wrote: > > If I use add_library(lzma ...) and PREFIX "lib", isn't the end > > result practically identical to the current method? Or is it more > > about coding style and "liblzma" looks weird? > > > This was just more of a coding style since not many people usually > care to force a lib prefix on msvc built dlls. > In my opinion, I would say that forcing lib prefix is a bit weird, OK. I know it's a bit weird but I also think the alternative is worse. > but it might be fine in lzma's case since even CMake uses libLZMA > https://cmake.org/cmake/help/latest/module/FindLibLZMA.html Hmm... its source code is baffling. Sounds like they used LZMA SDK and decided to move to liblzma without changing the CMake module name, which is weird because for some tasks LZMA SDK is the best or even the only choice. This also makes me wonder if I should use xz::liblzma to avoid a case-insensitive namespace conflict with FindLibLZMA. liblzma has always installed a pkg-config file and CMake can use them too. It's unfortunate that it wasn't enough. Perhaps it's due to Windows again where liblzma.pc is missing. On the other hand, there's no #definition of LZMA_API_STATIC for static linking in FindLibLZMA so Windows support doesn't fully explain it either. > > Is there a need for liblzma-only CMake support outside Windows? > > I guess one main usage would be in the cases where another project > uses CMake and pulls liblzma as a dependency and builds it in > situations where a system provided liblzma is not available. It would > be easier for those people to just use external_project without a lot > of configuration with native CMake support instead of worrying about > if bash or sh is available for configure Makes sense. Even if Windows might be the only CMake-supported OS that lacks the capability to easily run configure, it's much simpler to stay within the same build system type. Perhaps this can be considered later. -- Lasse Collin | IRC: Larhzu @ IRCnet & Freenode
