[cmake-developers] slow regex implementation in RegularExpression

James Bigler jamesbigler at gmail.com
Wed Nov 23 11:43:00 EST 2011


On Wed, Nov 23, 2011 at 8:36 AM, Bill Hoffman <bill.hoffman at kitware.com>wrote:

> On 11/22/2011 4:39 PM, Brad King wrote:
>
>  It is tempting to always require explicit requests for new TRE behavior,
>> such as using "TRE" instead of "REGEX" in keyword locations, but one
>> advantage of using a policy is that over time the old behavior will
>> disappear completely from usage.
>>
>>  I am pretty sure the last time we talked about adding a new regex we
> talked about requiring explicit requests.  I think this would be a much
> safer approach.  I am really scared that this regex will not be compatible
> with the old one, and it will break lots of stuff in very subtle ways that
> are hard for people to detect.  It is not that much code to have both.
>  Where performance is an issue, we can swap it out, and when people need
> better regex they can use TRE as well.  I don't think the pain will be
> worth getting rid of the old usage.
>
> -Bill
>
>
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/**
> opensource/opensource.html<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<http://www.cmake.org/Wiki/CMake_FAQ>
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/cgi-**bin/mailman/listinfo/cmake-**developers<http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers>
>

Why can't this be solved with a policy?  One problem of using an explicit
TRE command is that if you want to write code that *could* be used in an
older version of CMake you won't be able to use it.

I agree that making the usage explicit would allow for complete backward
compatibility, but it clutters the language.  Do you want to have two
versions of every regular expression syntax?  GLOB vs GLOB_TRE? MATCHES vs
MATCHES_TRE?

Another argument against using TRE explicitly is these words tell me
nothing about what that function does unless I'm extremely familiar with
the intricacies of CMake script.  I think we want to make CMake easier to
use, not harder.

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20111123/90fec474/attachment.html>


More information about the cmake-developers mailing list