On Thu, May 18, 2017 at 12:44:57 -0700, Alan W. Irwin wrote: > So your unit tests for regular expressions obviously missed at least > this issue. I have no idea what those unit tests are (or even if they > exist), but one possibility for attempting to wring most of the bugs out > of your regular expression processor is to adapt some other project's > regexp test suite. See > <http://stackoverflow.com/questions/15819919/where-can-i-find-unit-tests-for-regular-expressions-in-multiple-languages> > for a rather large list of such test suites.
This would be a great addition to CMake and would help with a future replacement to ensure that we are compatible with what is being used now. > 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. This has been brought up before. The regex engine used in CMake is *old* and, after my performance fixes a few years ago, is (or, at least, was) near the top of that list for various reasons. The biggest problem facing a replacement is the backwards compatibility. Do we want to just use a standard set of features (C++14?) and break unknown number of `MATCHES` expressions? This would require a policy and the old code would still lurk so that we can support the OLD policy. Or do we translate from what we support now into a standard language and then use another engine for that? This is probably the better solution for CMake, but is probably more code than the current engine. > From my perspective as a strongly interested CMake user (but not a > CMake developer or regexp guru) that wants a completely reliable > regular expression engine for CMake, I don't care which of these two > approaches you use to achieve that goal. But I hope my starting > this topic here will facilitate reaching that goal. I understand the want for a better engine, but just replacing it outright isn't really an option. Thanks, --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
