> On 11/24/2011 12:34 AM, Brad King wrote: >> On 11/23/2011 5:43 PM, Brad King wrote: >>> On 11/23/2011 12:44 PM, Brad King wrote: >>>> However, the above does not need to stand in the way of solving the >>>> problem you're addressing. We can simply set that goal aside for >>>> now by not exposing TRE in the CMake language anywhere. Use it >>>> just for cmCTestBuildHandler. >>> >>> but people kept going on "the above" part of the debate ;) >> >> After some more thought, I've realized that no approach currently >> proposed is practical: >> >> - cmCTestBuildHandler can use a list of custom regular expressions >> so we cannot assume all of them will be compatible with TRE
Use the old regex handler for all user supplied expressions and use TRE only for the internal ones? >> - As David Cole pointed out there are many places, like CTest's >> "-R" and "-E" options, that use regular expressions in contexts >> where we cannot possibly use a policy. Any attempt to do so in >> such places would just turn into a second API to set the policy >> in the local context of the regex. Either use your way as specified below or just document that these places only understand the old regex language. These places will have very few regexes for an at most moderate number of lines, so the huge speed improvement of TRE will not really hit you here. [...] >> (?#OLD)... # old >> (?#TRE)... # TRE >> >> This is quite easy to implement. Just take the currently proposed >> patch that replaces use of cmsys::RegularExpression with the new >> cmFastRegularExpression wrapper (perhaps renamed cmRegularExpression). >> Inside the wrapper look for a leading comment of the above form to >> decide which regex impl to use internally. Then strip off the prefix >> and pass the rest of the regex to the underlying implementation. >> Once this is done update all the default warning and error regular >> expressions that CTest uses. Add the (?#TRE) prefix to them. >> >> This approach will solve the speed problem, give people access to the >> TRE extended features when they want it anywhere CMake already uses >> a regex, has no compatibility problems, is a very narrow second >> interface, and is extensible for future optional regex behavior. > I like that proposal a lot, although I'm afraid it is a bit verbose. > Some of my regexes are already pretty lengthy, pushing the 80-columns > limit. For things that are inside CMakeLists.txt we then could introduce a global flag that decides what to do with unprefixed expressions: SET(CMAKE_PREFERED_REGEX_STYLE TRE) The default will of course will be "CMake" or however this will be called. And then a lazy user may just change it to something sensible ;) Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake