[cmake-developers] Making kwsys a proper library

[David Cole]

Honestly, KWSys has always seemed like a boost-avoidance mechanism
from an outsider's perspective. Perhaps it should be replaced with
boost equivalents in projects that need to be packaged for Fedora.

I assume all the boost libraries are already packaged/available.


Fuel for the fire, ;-)
D



On Fri, Aug 21, 2015 at 9:27 AM, Brad King <brad.king at kitware.com> wrote:
> On 08/20/2015 10:19 PM, Orion Poplawski wrote:
>> The consensus of the FPC is that the current situation with KWSys is
>> very undesirable.  While this approach may have been reasonable years
>> ago with few consumers, it does not seem acceptable at this point.
>
> FWIW, the origin of this is the following:  Many, many projects have
> their own custom code for many of the things KWSys is doing, but they
> may not organize the implementations into a distinguishable "library".
> This does not seem to be a problem for packaging these projects even
> though they could be using third-party libraries instead.
>
> We have several projects that all want some of these things as details
> of their implementation but we do not want to maintain a first-class
> library for them.  We could have had divergent implementations in
> each project like so many other unrelated projects do, but instead we
> decided to build infrastructure to share the common components of the
> source tree.  This gives our projects the benefits of common, well-
> tested infrastructure without the cost of maintaining a public-facing
> library for them.  If these implementations were not shared under the
> common "KWSys" banner then no one would have noticed that the projects
> appear to "bundle" a library.  How is this worse than other projects
> that do not share code at all?
>
> Yes, several components of KWSys appear to re-implement functionality
> that is now available in better third-party libraries.  However, much
> of it was added to our projects before those third-party libraries
> existed.  Things like the RegularExpression component came from other
> third-parties at the time who were also not providing first-class
> libraries for them.  Now they are kept in KWSys as a way to share the
> implementations among our projects at the source level.
>
>> Any and all efforts by the KWSys maintainers to split out KWSys into
>> proper libraries and perhaps pull out code that is only use by a single
>> project into that project would be greatly appreciated.
>
> Some components of KWSys are present for historical reasons and
> can be factored out or removed now.  This will be a worthwhile
> cleanup regardless of the above discussion.
>
>> be greatly appreciated if KWSys using projects would include in their
>> tarballs only those components that they actually used.
>
> Prior to CastXML, KWSys has only been included in projects that are
> much, much larger than itself and use most of its components so its
> size has not stood out before.  I've now reduced the KWSys sources
> inside CastXML to the minimum it needs.  Further discussion on the
> CastXML side would be better held on its own mailing list.
>
> -Brad
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers