Dear Lasse,
On 15.02.20 15:41, Lasse Collin wrote:
On 2020-02-15 Mario Emmenlauer wrote:
Would you consider integrating cmake support?
Maybe. I remember this being asked on IRC years ago but I wasn't able to
think about it back then. If it is enough to have CMake support to
build liblzma on a few very specific targets, it shouldn't be too hard
to add it *and* keep it maintained.
Supporting more than liblzma (like the xz tool) and many operating
systems would be too much work. Such a full support would require
porting the various Autoconf tests to CMake, testing the tests, and
keeping them up to date when the Autoconf tests are updated.
I think that is a perfectly reasonable approach. It will also give you
time to get acquainted with cmake at a low entry cost, while providing
hopefully significant benefit to users with less common build
configurations.
My reason for asking is that I've been using unofficial cmake patches
since a while to build xz on MSVC, and its always difficult to build
trust into every new release.
There are Visual Studio project files in XZ Utils to build liblzma. Are
those project files problematic or not good enough?
Admittedly I did not use them, because I'm very keen on using the same
build configuration (with respect to hardware optimizations and compiler
settings) in my full build stack. It seemed easier to re-generate the
project files than to validate what options they set (albeit I may be
considered a bit pedantic there).
Even if they are fine, I admit it could be nice if CMake could be used
instead, since maintaining the VS project files is a bit annoying and I
don't even test them.
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.
For what its worth there would be existing cmake integration that
can be used as a head start, i.e. from vcpkg.
A link to a known good CMakeLists.txt (and possible other files) would
be nice along with an explanation what it builds (e.g. both static and
shared liblzma?) and which targets are supported (e.g. is it MSVC
only?). Thanks!
If you consider this an option, I could make a proposal in a feature
branch. 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. Please
don't get discouraged when you browse their source - its just split
into patches that would not necessarily be required.
One more question: I would not start with an auto-generated header for
config.h but follow a similar approach to the current win32 headers.
Is that acceptable for a start?
All the best,
Mario Emmenlauer
