https://bugzilla.redhat.com/show_bug.cgi?id=1251500 Ben Boeckel <mathstuf@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mathstuf@xxxxxxxxx --- Comment #13 from Ben Boeckel <mathstuf@xxxxxxxxx> --- *Puts CMake upstream hat on* kwsys is meant to be copied on use (like gnulib). Making an external library of it (even static) means reworking how *all* projects with kwsys even use it today. *All* symbols are mangled in it and you'd end up with N copies of kwsys anyways: one with a cmsys (cmake) namespace, another with vtksys (VTK and ParaView), and itksys (ITK). It'd probably just need to ship the source so the files can be configured just as they are. But then you hit the "no ABI guarantee" problem between the projects. One thing that we can do is strip kwsys down and move functionality which only CMake cares about into CMake itself. This, however, seems to still leave a large intersection between VTK, ParaView, and ITK: - STL compatibility with *old* compilers; may go away as CMake doesn't self-host on some of these older compilers such as Borland 5; - directory listings; - glob support; - command line argument parsing; - regular expression; - md5 and base64 routines; - system information (e.g., number of processors); - hash_map and hash_set implementations (or just typedefs if supported); - process launching; - share library support (dlopen and the like); and - SystemTools (file path and filesystem utility functions). I think kwsys should really get the FPC exception as gnulib has, so I vote for "use Provides: bundled(kwsys)" or something. It may even make sense to hack the version/release of the Provides to indicate the upstream revision of it and the mangled namespace such as "20150803-1.gitdad68c33.cmsys" (for CMake master right now). -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review