Re: [cmake-developers] Making kwsys a proper library
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.k...@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 -- 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
Re: [cmake-developers] Making kwsys a proper library
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
Re: [cmake-developers] Making kwsys a proper library
On 08/21/2015 10:58 AM, Ben Boeckel wrote: CMake would have to ship with multiple versions of Boost, each subsetted and likely patched. That is hardly better. This falls under the category of third-party libraries that are candidates for use in the already-proposed cleanup of KWSys: On 08/21/2015 09:27 AM, Brad King wrote: 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. Some of the dependents may need to find alternatives as part of this cleanup, but selections will need to be made on a per-case basis. -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
Re: [cmake-developers] Making kwsys a proper library
On Fri, Aug 21, 2015 at 10:35:58 -0400, David Cole via cmake-developers wrote: 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. While I do love me some Boost, it doesn't provide process launching APIs, so you'd still need to handle that. Plus, Boost's lack of a stable API/ABI across the large range of versions that would need to be supported (e.g., there is no Boost release which supports VS7.1 and VS2015 at the same time, nevermind some of the more obscure compilers CMake expects to self-host on). And you'd need to both support filesystem2 and filesystem3 in client code, so it's not just a problem at the get boost building level. IMO, it would be *much* worse since CMake would have to ship with multiple versions of Boost, each subsetted and likely patched. That is hardly better. --Ben -- 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
Re: [cmake-developers] Making kwsys a proper library
On 08/17/2015 09:52 AM, Brad King wrote: On 08/15/2015 12:20 AM, Orion Poplawski wrote: What makes the kwsys code special in a way that makes creating a shared library inappropriate? We want to share the code across projects but we don't want it to get in the way of those projects evolving or releasing. KWSys has no version number or API version level, and we don't want to maintain one. Exactly one version of KWSys is used by each version of our consuming projects, down to the granularity of individual commits on each side. We want to remain free to make incompatible changes at any time. Dependents update their source and port to such changes when they are ready, not when some user decides to try that particular combination of versions. We don't have to worry about mixing versions in different dependents (due to prefix configuration), or about forward or backward compatibility on either end of the dependency arrows (due to version locking at the source level). -Brad 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. In particular it contains string processing and process handling code that could be security sensitive. See http://meetbot.fedoraproject.org/fedora-meeting-1/2015-08-20/fpc.2015-08-20-16.00.log.html for a full transcript of the meeting. 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. It would also be greatly appreciated if KWSys using projects would include in their tarballs only those components that they actually used. Currently Fedora will start marking KWSys using projects with a: Provides: bundled(kwsys-COMPONENT) tag to try to keep track of what each project uses. We hope to revisit the situation in the future. Thank you for your consideration. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- 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
Re: [cmake-developers] Making kwsys a proper library
On 08/15/2015 12:20 AM, Orion Poplawski wrote: What makes the kwsys code special in a way that makes creating a shared library inappropriate? We want to share the code across projects but we don't want it to get in the way of those projects evolving or releasing. KWSys has no version number or API version level, and we don't want to maintain one. Exactly one version of KWSys is used by each version of our consuming projects, down to the granularity of individual commits on each side. We want to remain free to make incompatible changes at any time. Dependents update their source and port to such changes when they are ready, not when some user decides to try that particular combination of versions. We don't have to worry about mixing versions in different dependents (due to prefix configuration), or about forward or backward compatibility on either end of the dependency arrows (due to version locking at the source level). -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
Re: [cmake-developers] Making kwsys a proper library
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 -- 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
Re: [cmake-developers] Making kwsys a proper library
On Thu, Aug 13, 2015 at 20:36:55 -0600, 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? Not right now. The thing is that each library which uses it mangles all of the symbols individually by configuring the source files, so without rewriting how kwsys is *used* in all of its downstream projects (cmake, VTK, ITK, and likely others), kwsys would likely have to be shipped as source anyways. https://fedorahosted.org/fpc/ticket/555 I commented here that castxml is more than a random xml app but will be needed for an updated ITK (at least; other projects might migrate to it from gccxml as time goes on). --Ben -- 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
Re: [cmake-developers] Making kwsys a proper library
On 08/14/2015 08:27 AM, Ben Boeckel wrote: On Thu, Aug 13, 2015 at 20:36:55 -0600, 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? Not right now. The thing is that each library which uses it mangles all of the symbols individually by configuring the source files, so without rewriting how kwsys is *used* in all of its downstream projects (cmake, VTK, ITK, and likely others), kwsys would likely have to be shipped as source anyways. That's certainly what I've found at the moment. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- 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
[cmake-developers] Making kwsys a proper library
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? See also: https://bugzilla.redhat.com/show_bug.cgi?id=1251198 https://fedorahosted.org/fpc/ticket/555 https://bugzilla.redhat.com/show_bug.cgi?id=1251500 Thanks -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- 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
