[Cmake] Regular expression ++ nesting problem

David Svoboda xsvobod2 at informatics.muni.cz
Mon, 1 Mar 2004 09:26:48 +0100


On Fri, 27 Feb 2004, Brad King wrote:

> David Svoboda wrote:
> > On Thu, 26 Feb 2004, Brad King wrote:
> >
> >
> >>David Svoboda wrote:
> >>
> >>>Hello,
> >>>
> >>>I used the following construction:
> >>>
> >>>IF ("${MY_STRING_PATH}" MATCHES "${CHOSEN_PATH}.*")
> >>>	...
> >>>
> >>>
> >>>to test, whether CHOSEN_PATH is included in MY_STRING_PATH. Everything had
> >>>worked well until I tried SET(CHOSEN_PATH /usr/local/packages/g++-3.0).
> >>>Here the variable CHOSEN_PATH contains the "+" sign (twice) and causes
> >>>errors in CMake:
> >>>
> >>>
> >>>***
> >>>-- Check for working C compiler: gcc -- works
> >>>-- Check for working CXX compiler: g++-3.0 -- works
> >>>RegularExpression::compile(): Nested *?+.
> >>>RegularExpression::compile(): Error in compile.
> >>>RegularExpression::compile(): Nested *?+.
> >>>RegularExpression::compile(): Error in compile.
> >>>-- Configuring done
> >>>-- Generating done
> >>>***
> >>>
> >>>
> >>>I tried some "\" or "'" signs, but it did not work. Could anybody help me?
> >>
> >>The "MATCHES" expression in an IF statement should always be written by
> >>hand due to the reason you just encountered.  If you have a string you
> >>want to compare, use the "STRING" command.  See "cmake --help STRING"
> >>for details.
> >>
> >>-Brad
> >>
> >
> >
> > I looked through the STRING(...) help. The most suitable seems the command
> >
> > 	STRING(COMPARE LESS <string1> <string2> <output variable>)
> >
> > But this command compares the length of the strings - not the string
> > themselves. Hence I do not know, how to test wheter the string
>
> It does compare the strings themselves, but it is not intended to
> identify substrings.  Take a look at Source/cmStringCommand.cxx if you
> would like to contribute more advanced string operations.
>
> > 	/usr/local/packages/omniorb-4.0.1-g++-3.0
> >
> > is substring of
> >
> > 	/usr/local/packages/omniorb-4.0.1-g++-3.0/bin/omniidl
> >
> > for example. Or more precisely, if the directory
> >
> > 	/usr/local/packages/omniorb-4.0.1-g++-3.0
> >
> > contains subdirectory or application
> >
> > 	/usr/local/packages/omniorb-4.0.1-g++-3.0/bin/omniidl
>
> In that case you'll have to write a loaded command or find another way
> to implement this logic.  You could try going back to the MATCHES
> approach, but first use STRING(REGEX REPLACE ...) to escape the special
> characters.  What is your ultimate goal for this test?

I wrote a macro, which is capable of managing include a lib files. If I
set the path to the library/package (e. g. /usr/local/odbc), the macro
fills in the appropriate switches and parameters to the compiler and
linker. In this case -I/usr/local/odbc/include and -L/usr/local/lib/odbc
-lodbc are added to cimpiler and linker, respectively.

And now the reason, why I want to compare strings - if the user changes
the library version, e.g. to odbc-1.3, the appropriate path for include
dirs and linker dirs must be changed. Most important is the comparison of
the string - whether the user changed the library version - i. e. testing
for any changes.

I have already found the solution! I have left the idea of comparing
substrings and created new cache variable - here I embedded the
STRING(COMPARE EQUAL ...) command and it works very well!


-David