On 05/18/2017 03:44 PM, Alan W. Irwin wrote: > Another possibility is simply to forget supporting your own regexp > engine and adopt someone else's very well regarded regexp engine (such > as libprng). I vaguely recall that has been suggested before, but > since that hasn't happened I presume inertia or NIH syndrome won or > else there was some strong reason why you didn't go that route.
When CMake started there were very few BSD-licensed regex implementations. The one we currently use was one of the few available at the time. It is not something we wrote ourselves. The regex syntax is public-facing in CMake's interface, both in CMake language code and on the command line. Therefore any replacement will have to interpret the input expressions exactly the same way as they are interpreted now (except for ()-group limits and corner case bugs). There was discussion in a thread in Nov 2011 about replacement strategies: * https://cmake.org/pipermail/cmake-developers/2011-November/014249.html * https://cmake.org/pipermail/cmake-developers/2011-November/014277.html * https://cmake.org/pipermail/cmake-developers/2011-November/014291.html * https://cmake.org/pipermail/cmake-developers/2011-November/014294.html * https://cmake.org/pipermail/cmake-developers/2011-November/014353.html * https://cmake.org/pipermail/cmake-developers/2011-November/014362.html * https://cmake.org/pipermail/cmake-developers/2011-November/014376.html *** * https://cmake.org/pipermail/cmake-developers/2011-November/014379.html The one I marked `***` is the current state of the design space AFAIK. I think the path forward is some combination of: * Replace the implementation of the old regex syntax by transforming old expressions to use some new regex engine such that matching is identical. This can be done regardless of whether the new engine's syntax is made public-facing (by the following steps). * Use `(?#TRE)` or a similar prefix in expressions to explicitly request a new regex impl for them. Then name "TRE" in this example corresponds to one particular regex library that was discussed in the above thread. Other names/libs could be used so long as they are BSD-licensed. Or, we could consider using the <regex> in the C++ standard library, but that will have to wait until we finish modernizing CMake's requirements for C++ compilers. * Use a policy to switch all regexes within CMake language code. If anyone is interested in working on this please post. -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
