On 2020-02-28 Mario Emmenlauer wrote:
> It seems I did find an impediment, after all. I've back-ported the
> CMakeLists.txt to xz-5.2.4 as described before. The only change
> required was to remove two source files,
> src/liblzma/common/file_info.c and src/liblzma/common/index_decoder.h.
This shou
On 27.02.20 20:52, Lasse Collin wrote:
On 2020-02-27 Mario Emmenlauer wrote:
Awesome! I've just tested the CMakeLists with the latest official
release xz-5.2.4 and it works flawless so far.
Anyway, more feedback from CMake users is welcome. The liblzma part
should work on multiple operating sy
On 2020-02-27 Mario Emmenlauer wrote:
> Awesome! I've just tested the CMakeLists with the latest official
> release xz-5.2.4 and it works flawless so far.
Thanks!
I got some off-list feedback about the CMake files in xz.git so I know
that at least something about them works (static builds with MS
Dear Lasse,
On 24.02.20 23:12, Lasse Collin wrote:
Hello!
I committed some CMake support. It should support a few platforms (not
just Windows) for building liblzma but it's not tested. Silly bugs are
very much possible.
The CMakeLists.txt in the previous email had a bug in the defines: they
Hello!
I committed some CMake support. It should support a few platforms (not
just Windows) for building liblzma but it's not tested. Silly bugs are
very much possible.
The CMakeLists.txt in the previous email had a bug in the defines: they
lacked quotation marks for the strings. The questions in
On 2020-02-17 Mario Emmenlauer wrote:
> I think the conan community also enjoyes cmake because it integrates
> very well. So, since this CMakeLists.txt is quite well developed its
> not unlikely that more people looking mostly for liblzma will try to
> switch to cmake.
OK. I hadn't thought much ab
Dear Lasse,
awesome! Great work!
On 17.02.20 01:54, Lasse Collin wrote:
>>> 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 whe
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 ll
On Sun, Feb 16, 2020 at 4:48 PM Lasse Collin
wrote:
> > - 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://c
>
> 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
requirem
On 2020-02-16 Lasse Collin wrote:
> I quickly checked a few random things and didn't find anything else
> that wouldn't be OK with 3.1.
target_link_options needs 3.13. Seems that it can be avoided by using
set_target_properties(liblzma PROPERTIES LINK_FLAGS
-Wl,--version-script=${CMAKE_CURREN
On 2020-02-16 Christopher Degawa wrote:
> I'm not a xz developer, but more of a user, I hope these can be of
> use to you
Thanks! I'm sure you have more experience about CMake than I do. :-)
> - Although you mark your cmake minimum as 3.1, your project command
> contains `DESCRIPTION`, and `HOMPA
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
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 mak
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
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
t
Dear developers,
I could not find the topic in the archives or forum, so I thought I
kindly ask: Would you consider integrating cmake support? 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 ev
17 matches
Mail list logo
