[cmake-developers] Making kwsys a proper library

[Brad King]

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