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