|
Boost : |
Subject: Re: [boost] The future and present of Boost
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2018-10-24 08:32:53
On Wed, 24 Oct 2018 at 00:41, Raffi Enficiaud via Boost
<boost_at_[hidden]> wrote:
> I would make an effort to end the life of some libraries, rather than
> ending the life of boost or their maintainers. Boost should accept it
> successes and its failures.
>
> - Is boost.test a success? I think it is, I am biased though. I would
> love to drop support for C++03 to get rid of all the intra-library
> dependencies that are polluting the usability.
>
> - Is uBlas a success? If we get things done to accelerate, certainly.
> Otherwise I will just use Eigen as before.
>
> - Is GIL a success?
> [...]
Please, present a definition of success or failure as basis to
qualify a library for removal from Boost.
FYI, GIL has been abandoned, but thanks to Stefan Seefeld,
who joined long lonely wolf of GIL, Christian Henning,
it's maintenance has been reactivated.
A couple of months ago, I joined the efforts myself, as a long time GIL user.
GitHub spits around quarter of million of C++ files referring to `boost::gil`,
there some larger projects that use it (I know of TuttleOFX, K-3D).
I do think that Boost has become overweight and
must gain some lean working mass sooner than later.
GIL still directly depends on (too) many libraries:
libs/bind
libs/concept_check
libs/config
libs/core
libs/crc
libs/filesystem
libs/function
libs/integer
libs/iterator
libs/lambda
libs/mpl
libs/numeric/conversion
libs/preprocessor
libs/static_assert
libs/test
libs/type_traits
(We are working on cutting the list down and I have personally
planned lots of refactoring in this area - if only there was 48/7 not 24/7.)
So, from my perspective, major advantage of having GIL in Boost is to keep
life of GIL users and developers easier.
For me personally, working on Boost.GIL rather than just GIL is also a great
opportunity to hang out with super-brains of C++, listen, ask and learn from the
community on ML-s, IRC or Slack. That is also a source of motivation to act
in Boost areas beyond GIL.
For some Boost.GIL may sound more prestigious than just GIL.
Having said that, I'd like to see GIL as part of Boost, selfishly, at least for
as long as I keep contributing to it.
If, however, GIL is kicked out from Boost, it will not be the end of the world,
neither for GIL nor for me personally as GIL user and maintainer.
It would bring many challenges but also opportunities.
Best regards,
-- Mateusz Loskot, http://mateusz.loskot.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk