[cmake-developers] Making kwsys a proper library

[Orion Poplawski]

On 08/14/2015 08:11 AM, Brad King wrote:
> On 08/13/2015 10:36 PM, Orion Poplawski wrote:
>> There is concern in Fedora that the kwsys code has become too large to
>> be an acceptable copylib.  However, as cmake is constructed at the
>> moment it would be a huge undertaking for the Fedora packagers (mostly
>> me) to remove it downstream.  So I'm asking if there is any support
>> upstream for making kwsys a proper library?
>
> KWSys is a copylib by design.  Each project using it configures the
> library with a different namespace/prefix, can enable different
> subsets of the library, and can choose some behavior toggles.  Some
> projects maintain local patches to their copy of KWSys that are
> good enough for themselves but not for upstream.  KWSys cannot be
> shared by multiple such clients as a single library and should
> *never be distributed as a packaged binary*.
>
> If each of Kitware's projects using KWSys maintained the code
> separately under different hard-coded names (cmsys, vtksys, itksys,
> etc.) then no one would be expecting it to be a separate library.
> The shared KWSys source helps share maintenance among these projects
> while still each getting a custom library that never conflicts with
> the others.
>
> -Brad

Yeah, it's very clear that that is how it is at the moment.  I guess I'm 
asking if that is an appropriate design for a decent size chunk of code. 
  What makes the kwsys code special in a way that makes creating a 
shared library inappropriate?  There may indeed be valid reasons, but I 
just don't know them.  You mentioned behavior toggles - that seems like 
a likely candidate - could you give a bit more detail?

Thank you very much for your time and response.  Really.

PS - I don't want to come off like a jerk asking this, although that 
seems almost inevitable with email.  I'm also a bit frustrated from my 
experiences as a member of the Fedora Packaging Committee as it seems 
with the rise of git submodules it's becoming easier and easier for 
projects to share code by bundling rather than via shared libraries. 
This seems to negate all of the positives of shared libraries (reduced 
code and memory usage, delivery of bug/security fixes via a single 
update, etc) for the convenience of not having to deal with maintaining 
a stable API/ABI. </rantoff>

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com