From: Jeff Bonyun (jeff_at_[hidden])
Date: 2019-05-24 15:42:30
>> So basically if someone has an older lzma they are limited to boost
>> 1.70.0 or earlier. That's perhaps reasonable as long as it is
>> documented, but it hasn't been the typical way I have seen things
>> added to existing code.
> Well, my second question was if you are confident that 1.70 does actually
> work with liblzma versions older than 5.1.1? If this isn't tested, it is not
> supported and if it is not supported it imho makes little sense to complicate
> the source code to achieve potential compatibility with (what I assume to be)
> a very, very small number of setups.
I will be testing, with and without my additions, with every numbered
version of liblzma before making my pull request. So I'll be able to
answer that soon. But that doesn't deal with your real concern: that
testing will not be automated and ongoing, and it could mysteriously
break in the future.
My production systems are RHEL 6. They have a 4.x version of liblzma
installed by the package manager, which is incompatible with the changes
I am making. I get that RHEL 6 is old, but some industries have to deal
with that sort of thing.
> However, as long as the interface is untouched by this macro I guess it would
> be fine.
The design I have right now would leave the interface the same between
the macro on and the macro off. I.e. both would have a new "threads"
argument and member. The macro would be used only in the cpp file.
Working code would work in all cases. Requests for different numbers of
threads would just be ignored if it isn't supported.
The deeper questions here are above my pay grade. I will bend to the
whims of those with more experience maintaining boost.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk