Re: [CMake] wrapper around real compiler
Hi. What scl enable devtoolset-2 does, is basically change the environment for the command. I use one of two techniques to make it working. When doing manual builds, I simply: scl enable devtoolset-2 bash And do everything from the new shell. On our CI, I put the following in build script (before calling cmake): . /opt/rh/devtoolset-2/enable As there is no magic but only environment variables involved, you can probably set them all using -DCMAKE_... options. Just look at the script and set, what you need. Remember, that devtoolset-2 is really just GNU Toolset in 4.8 version installed in non-standard location. -- Gruesse, Jakub From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Tomasz Majchrowski Sent: Dienstag, 11. März 2014 19:44 To: cmake@cmake.org Subject: [CMake] wrapper around real compiler Dear All, I found cmake provides many techniques to integrate tools like distcc, ccache into the build system. In particular variables like the following could be used: -D CMAKE_C_COMPILER="ccache" -D CMAKE_C_COMPILER_ARG1="gcc" The picture becomes more complicated when the tools around the real compiler requires "special" syntax. As an example the RedHat's scl is such a one as it's requires quotation of the complete compiler line: scl enable devtoolset-2 'g++ -o output_file source_file...' Details: https://access.redhat.com/site/documentation/en-US/Red_Hat_Developer_Toolset/2/html/User_Guide/sect-GCC-CPP.html I was playing with build rules, however didn't success on try_compile which seems to ignore them. set ( CMAKE_C_COMPILE_OBJECT " enable devtoolset-2 ' gcc -frandom-seed=/ -o -c ' ") The only working one that I found is to use small bash script which will act as yet another wrapper. Anyway this solution do not looks "elegant" and I would like to avoid. Can anyone suggest a good method how to cope with this issue ? -- Pozdrawiam/Best regards/Mit freundlichen Grüßen, Tomasz Majchrowski, Information Technology and Services Consultant and Contractor -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Using Qt5 with CMake
Alan W. Irwin wrote:
> (1) How should you replace
>
> find_package(Qt4 4.8.2 COMPONENTS QtCore QtGui QtSvg)
find_package(Qt5 5.2.1 COMPONENTS Svg)
or
find_package(Qt5Svg 5.2.1)
Packages and targets know their dependencies so you don't have to.
> and
>
> qt4_wrap_cpp(
>QT_MOC_OUTFILES
>${CMAKE_SOURCE_DIR}/include/qt.h
>OPTIONS ${MOC_OPTIONS}
>)
qt5_wrap_cpp(
QT_MOC_OUTFILES
${CMAKE_SOURCE_DIR}/include/qt.h
OPTIONS ${MOC_OPTIONS}
)
Though you can port to AUTOMOC before/after porting to Qt 5 too.
> Does Qt5
> still use that directory property apprach for setting compile flags
> or is this no longer an issue?
Qt 5 provides IMPORTED targets which have the compile flags encoded in them.
The flags are consumed by target_link_libraries.
http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html
target_link_libraries(foo Qt5::Svg)
Qt4 provides IMPORTED targets too, so you can already use those before
porting to Qt 5 instead of whatever mechanism you currently use.
target_link_libraries(foo Qt4::QtSvg)
http://www.cmake.org/cmake/help/v3.0/manual/cmake-qt.7.html
> target_link_libraries(
>plplotqt${LIB_TAG}
>plplot${LIB_TAG}
>${MATH_LIB}
>${QT_LIBRARIES}
>)
>
> How should that command be replaced for the new Qt5 way of doing
> things?
I recommend listing the IMPORTED target 'leaf' dependencies.
target_link_libraries(
plplotqt${LIB_TAG}
plplot${LIB_TAG}
${MATH_LIB}
Qt4::QtSvg
# Qt5::Svg
)
You can use
set(QT_LIBRARIES Qt4::QtSvg)
either, but I recommend using the target names directly.
Thanks,
Steve.
--
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://www.cmake.org/mailman/listinfo/cmake
[CMake] Target Link Library
Hi,
My cross platform project has a main module and a custom library. The main
module depends on the custom library. Both these projects need to be built
with cmake. At present the option I find to set this is to using the
"target_link_library(MyExe ${CMAKE_CURRENT_BINARY_DIR}/myLib.lib)". But
this code makes my cmake file platform dependent, that is on windows I need
to use the "MyLib.lib" in CMake and on Linux I need to use "MyLib.a" ! Is
there a better alternative? (I went through the doc of find_library(), but
it doesn't seem to be suitable in this scenatio)
Thanks,
Lloyd
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] wrapper around real compiler
Thank you Jakub for reply. The build environment is used by group of
colleges distributed across the glob. Therefore I would like to avoid new
rules
like enter new shell before build as this will change the way how they are
doing the daily job (means: cmake .. ; make ). Since build with cmake
is two stage process, first cmake and second make, any shell variables set
in cmake call via: set( ENV{PATH} ... will be lost in the context of make
process.
The working solution is to use wrapper which will get options without
quotation and pass to scl with using of quota. I will go with this option
if can't provide
quotation with using of CMAKE_C_COMPILE_OBJECT. The issue that i see right
now is that rule defined by CMAKE_C_COMPILE_OBJECT is lost in try_compile
call
Best regards, Tomasz Majchrowski.
2014-03-12 8:26 GMT+01:00 Jakub Zakrzewski :
> Hi.
> What scl enable devtoolset-2 does, is basically change the environment for
> the command. I use one of two techniques to make it working. When doing
> manual builds, I simply:
> scl enable devtoolset-2 bash
> And do everything from the new shell. On our CI, I put the following in
> build script (before calling cmake):
> . /opt/rh/devtoolset-2/enable
> As there is no magic but only environment variables involved, you can
> probably set them all using -DCMAKE_... options. Just look at the script
> and set, what you need.
> Remember, that devtoolset-2 is really just GNU Toolset in 4.8 version
> installed in non-standard location.
>
> --
> Gruesse,
> Jakub
>
>
>
>
>
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Tomasz
> Majchrowski
> Sent: Dienstag, 11. März 2014 19:44
> To: cmake@cmake.org
> Subject: [CMake] wrapper around real compiler
>
> Dear All,
> I found cmake provides many techniques to integrate tools like distcc,
> ccache into the build system. In particular variables like the following
> could be used:
>
> -D CMAKE_C_COMPILER="ccache" -D CMAKE_C_COMPILER_ARG1="gcc"
> The picture becomes more complicated when the tools around the real
> compiler requires "special" syntax. As an example the RedHat's scl is such
> a one as it's requires quotation of the complete compiler line:
>
> scl enable devtoolset-2 'g++ -o output_file source_file...'
> Details:
> https://access.redhat.com/site/documentation/en-US/Red_Hat_Developer_Toolset/2/html/User_Guide/sect-GCC-CPP.html
>
> I was playing with build rules, however didn't success on try_compile
> which seems to ignore them.
>
> set ( CMAKE_C_COMPILE_OBJECT" enable devtoolset-2 '
> gcc -frandom-seed=/ -o -c ' ")
> The only working one that I found is to use small bash script which will
> act as yet another wrapper.
> Anyway this solution do not looks "elegant" and I would like to avoid.
>
>
> Can anyone suggest a good method how to cope with this issue ?
> --
> Pozdrawiam/Best regards/Mit freundlichen Grüßen, Tomasz Majchrowski,
> Information Technology and Services Consultant and Contractor
>
> --
> Pozdrawiam/Best regards/Mit freundlichen Grüßen, Tomasz Majchrowski,
> Information Technology and Services Consultant and Contractor
>
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Target Link Library
On 12.03.2014 09:58, Lloyd wrote:
My cross platform project has a main module and a custom library. The
main module depends on the custom library. Both these projects need to
be built with cmake. At present the option I find to set this is to
using the
"target_link_library(MyExe ${CMAKE_CURRENT_BINARY_DIR}/myLib.lib)".
But this code makes my cmake file platform dependent, that is on
windows I need to use the "MyLib.lib" in CMake and on Linux I need to
use "MyLib.a" ! Is there a better alternative? (I went through the doc
of find_library(), but it doesn't seem to be suitable in this scenatio)
Assuming your library is being build by the project and not manually
being copied into the binary directory you can use the target name
instead of the filename of the library.
If you created the target with add_library(mylibrary ...)
target_link_library(MyExe mylibrary) should work.
CMake will fill in the actual full path to the library.
Nils
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Target Link Library
On 12.03.2014 10:41, Nils Gladitz wrote: If you created the target with add_library(mylibrary ...) target_link_library(MyExe mylibrary) should work. Sorry, I didn't realize I copied your incorrectly named target_link_library() call ... the actual command should be target_link_libraries(). Nils -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Target Link Library
Thank you very much for the simple and clean solution. Thanks, Lloyd On Wed, Mar 12, 2014 at 3:20 PM, Nils Gladitz wrote: > On 12.03.2014 10:41, Nils Gladitz wrote: > >> If you created the target with add_library(mylibrary ...) >> target_link_library(MyExe mylibrary) should work. >> > > Sorry, I didn't realize I copied your incorrectly named > target_link_library() call ... the actual command should be > target_link_libraries(). > > Nils > -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] ExternalProject_add combined with add_custom_command
Hi
In have two projects. One is the parent, the second one is the child. The
second one is the generator for the parent. I require to include the child
project inside the parent, build it and use the executable of the child to
generate files for the parent. I was able to include the child project and
build it in parent through ExternalProject_Add command. What I'm not able
to do is to use the executable from the child project and generate files
for the parent project. Can I get some help with this? An working example
combining these two functionalities? Here is how I do it:
include(ExternalProject)
set(code_gen_PREFIX "${PROJECT_SOURCE_DIR}/code_gen")
set(code_gen_SVN_URL "*/url/to/child/proj/*")
set(code_gen_CMAKE_ARGS -DCMAKE_BUILD_TYPE=Release;
-DCMAKE_INSTALL_PREFIX=${PROJECT_SOURCE_DIR}*/bins/*)
ExternalProject_Add(code_generator
PREFIX ${code_gen_PREFIX}
SVN_REPOSITORY ${code_gen_SVN_URL}
SVN_USERNAME ${code_gen_SVN_USER}
SVN_PASSWORD ${code_gen_SVN_PASS}
CMAKE_ARGS ${code_gen_CMAKE_ARGS}
STAMP_DIR ${code_gen_PREFIX}
)
add_executable(code_generator IMPORTED GLOBAL)
set_property(TARGET code_generator PROPERTY IMPORTED_LOCATION
"${PROJECT_SOURCE_DIR}*/bins/*")
add_custom_command(
OUTPUT file1 file2 file3 file4
COMMAND code_generator args_for_code_generator_app
COMMAND code_generator args_for_code_generator_app
)
Some notes:
Each call of the command outputs two files, that's why I have 4 files for
the output.
The step with ExternalProject_Add is working, all the variables are
properly set.
${PROJECT_SOURCE_DIR}*/bins/* is good, I checked it multiple times and
executable is on this path.
I get this type of error
*/bin/sh: 1:${PROJECT_SOURCE_DIR}/bins/*: Permission denied
Both of the projects are CMake projects.
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Using Qt5 with CMake
On 2014-03-12 01:15-0400 Jean-Christophe Fillion-Robin wrote:
Hi Alan,
To get a better idea of the required change to support Qt5, you could look
at what we did for VTK. See
https://github.com/Kitware/VTK/commit/384636ec9f4
Hth
Jc
Hi Jean-Christophe:
Thanks! That is a big help. I notice, for example, that VTK decided to
use the "Using Qt 5 with CMake older than 2.8.9" approach. I might
try that as well to start because it seems more understandable to me
than the alternative approaches that are also available with later
CMake versions which take advantage of new CMake infrastructure.
Alan
On Tue, Mar 11, 2014 at 4:59 PM, Alan W. Irwin wrote:
On 2014-01-26 17:36+0100 Stephen Kelly wrote:
http://doc-snapshot.qt-project.org/qt5-stable/cmake-manual.html
To resurrect this slightly old thread, it has been years since I
implemented the Qt4 parts of the PLplot build system, and I haven't
looked much at the Qt components of our build system ever since. So I
am basically starting again from virtually no knowlege concerning
CMake support for Qt to get the PLplot build system to find and use
the Qt5 components that it needs. I am frankly somewhat lost trying
to use the above documentation which seems rather incomplete from my
perspective. Another complicating factor at the moment is I don't
have access to Qt5 (running Debian stable) so, for now, I don't have a
chance to try some experiments to work things out, and others (who
have considerably less general knowledge than I do concerning the
PLplot build system) will be trying out what is recommended here
instead of me.
So here are some specific questions related to PLplot's future Qt5 needs.
(1) How should you replace
find_package(Qt4 4.8.2 COMPONENTS QtCore QtGui QtSvg)
and
qt4_wrap_cpp(
QT_MOC_OUTFILES
${CMAKE_SOURCE_DIR}/include/qt.h
OPTIONS ${MOC_OPTIONS}
)
(the two key commands the PLplot build system currently uses for Qt4)
with the new cmake finding infrastructure documented above?
(MOC_OPTIONS are some macros we set to control including or dropping
various parts of the PLplot qt.h header file.)
(2) PLplot currently does not use include(${QT_USE_FILE}) since in my
view that directory property approach is too blunt an instrument that
tends to contaminate the large parts of the PLplot build that have
nothing to do with Qt with all the Qt-related compiler flags. Instead,
we use the alternative approach of simply setting the appropriate Qt
compile flags for our specific Qt-related source files. Does Qt5
still use that directory property apprach for setting compile flags
or is this no longer an issue?
(3) Our current alternative to include(${QT_USE_FILE}) still sets
QT_LIBRARIES. That allows us to link one of the key PLplot Qt-related
libraries
as follows:
target_link_libraries(
plplotqt${LIB_TAG}
plplot${LIB_TAG}
${MATH_LIB}
${QT_LIBRARIES}
)
How should that command be replaced for the new Qt5 way of doing
things?
It appears from the above documentation that the new Qt5 find and use
methods are quite dependent on CMake version so assume for the
purposes of this question that our build system will force the PLplot
user to use CMake version 2.8.11 or higher by the time we have this
all debugged.
Thanks in advance for any help you can give with the specific
questions above for converting a project such as PLplot that currently
uses Qt4 to one that uses Qt5.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__
Linux-powered Science
__
--
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://www.cmake.org/mailman/listinfo/cmake
--
+1 919 869 8849
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net)
Re: [CMake] Using Qt5 with CMake
Hi Steve: Your answer was quite helpful, but I have one supplementary question. On 2014-03-12 09:34+0100 Stephen Kelly wrote: Alan W. Irwin wrote: (1) How should you replace find_package(Qt4 4.8.2 COMPONENTS QtCore QtGui QtSvg) find_package(Qt5 5.2.1 COMPONENTS Svg) or find_package(Qt5Svg 5.2.1) Packages and targets know their dependencies so you don't have to. Your statement appears to imply that QtSvg has a QtGui (and QtCore) dependency so I don't have to worry about those other components. That is great if true, but I need confirmation of that since I have very little knowledge of the Qt components, and how they depend on each other. Note, we use Qt to produce plots in a very wide range of non-interactive file formats as well using Qt to implement an interactive Qt plotting device. As far as I know QtSvg is required because one of the file formats is SVG, and QtGui is required for the interactive Qt-related device. But I am quite surprised that the QtSvg component depends on QtGui because I had always thought of the SVG standard as being completely file oriented. So your confirmation of that dependency would be appreciated. By the way after re-reading the documentation at http://doc-snapshot.qt-project.org/qt5-stable/cmake-manual.html, I have decided not to use the "Using Qt 5 with CMake older than 2.8.9" approach as I suggested earlier today. Instead, I will first try using the qt5_use_modules approach (which is natural since the PLplot minimum CMake version is already 2.8.9). Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Using Qt5 with CMake
Alan W. Irwin wrote: >> Packages and targets know their dependencies so you don't have to. > > Your statement appears to imply that QtSvg has a QtGui (and QtCore) > dependency so I don't have to worry about those other components. Correct. I suggest you create a project for experimentation such as this: find_package(Qt4 REQUIRED) find_package(Qt5Svg REQUIRED) add_executable(testexe main.cpp) target_link_libraries(testexe Qt4::QtSvg) #target_link_libraries(testexe Qt5::Svg) and look at the verbose output. Thanks, Steve. -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] Variable Containing "MSVC" and MATCHES
Hi,
I know that MSVC is a CMake keyword and it is therefore not a good idea to use
the string "MSVC" as the value for any variable, e.g. set( compiler "MSVC" ),
because if you aren't careful and interpret such a variable without surrounding
it with quotes (e.g. ${compier} rather than "${compiler}") you will get 0 or 1
depending on whether you are using a Visual Studio generator or not. So far so
good.
However, I was caught off guard by the fact that the MATCHES directive (for
regex matching) inside an IF() statement is apparently interpreting the strings
passed to it. Consider the following code:
if( "MSVC11" MATCHES "MSVC[0-9]+" )
message( STATUS "MSVC11 matches MSVC[0-9]+" )
endif()
if( "TEST11" MATCHES "TEST[0-9]+" )
message( STATUS "TEST11 matches TEST[0-9]+" )
endif()
The first MATCHES does not enter the IF() statement, while the second does. I'm
guessing that the string "MSVC11" (or the regular expression "MSVC[0-9]+") is
interpreted before regular expression matching can take place and "MSVC11"
becomes "111" or "true11" (or the regular expression "MSVC[0-9]+" becomes
"1[0-9]+" or "true[0-9]+").
Putting either the string or the regex or both into variables doesn't help
either. The only thing that prevents MSVC from being interpreted is putting
extra quotes into both the string and the regexp, i.e. "\"MSVC11\"" MATCHES
"\"MSVC[0-9]+\"".
Is there any type of interpretation happening on either the string or the regex
in an IF( MATCHES ) statement? If this is by design, i.e. not a bug, what are
the reasons for this?
Thanks,
P.S.: The following is an example CMakeLists.txt that demonstrates the problem
for easy testing:
cmake_minimum_required( VERSION 2.8.12 )
set( test "MSVC11" )
message( STATUS "Start matching string \"${test}\" ..." )
message( STATUS )
set( regex "MSVC" )
message( STATUS "... against regular expression: ${regex}" )
if( "${test}" MATCHES "${regex}" )
message( STATUS "\t\"${test}\" matches regular expression: ${regex}" )
else()
message( STATUS "\t\"${test}\" DOES NOT match regular expression: ${regex}"
)
endif()
message( STATUS )
set( regex "MSVC." )
message( STATUS "... against regular expression: ${regex}" )
if( "${test}" MATCHES "${regex}" )
message( STATUS "\t\"${test}\" matches regular expression: ${regex}" )
else()
message( STATUS "\t\"${test}\" DOES NOT match regular expression: ${regex}"
)
endif()
message( STATUS )
set( regex "MSVC[0-9]" )
message( STATUS "... against regular expression: ${regex}" )
if( "${test}" MATCHES "${regex}" )
message( STATUS "\t\"${test}\" matches regular expression: ${regex}" )
else()
message( STATUS "\t\"${test}\" DOES NOT match regular expression: ${regex}"
)
endif()
message( STATUS )
set( regex "MSVC[0-9]+" )
message( STATUS "... against regular expression: ${regex}" )
if( "${test}" MATCHES "${regex}" )
message( STATUS "\t\"${test}\" matches regular expression: ${regex}" )
else()
message( STATUS "\t\"${test}\" DOES NOT match regular expression: ${regex}"
)
endif()
message( STATUS )
message( STATUS "End matching ${test} ..." )
message( STATUS )
message( STATUS )
message( STATUS )
set( test2 "test11" )
message( STATUS "Start matching ${test2} ..." )
message( STATUS )
set( regex "test" )
message( STATUS "... against regular expression: ${regex}" )
if( "${test2}" MATCHES "${regex}" )
message( STATUS "\t\"${test2}\" matches regular expression: ${regex}" )
else()
message( STATUS "\t\"${test2}\" DOES NOT match regular expression:
${regex}" )
endif()
message( STATUS )
set( regex "test." )
message( STATUS "... against regular expression: ${regex}" )
if( "${test2}" MATCHES "${regex}" )
message( STATUS "\t\"${test2}\" matches regular expression: ${regex}" )
else()
message( STATUS "\t\"${test2}\" DOES NOT match regular expression:
${regex}" )
endif()
message( STATUS )
set( regex "test[0-9]" )
message( STATUS "... against regular expression: ${regex}" )
if( "${test2}" MATCHES "${regex}" )
message( STATUS "\t\"${test2}\" matches regular expression: ${regex}" )
else()
message( STATUS "\t\"${test2}\" DOES NOT match regular expression:
${regex}" )
endif()
message( STATUS )
set( regex "test[0-9]+" )
message( STATUS "... against regular expression: ${regex}" )
if( "${test2}" MATCHES "${regex}" )
message( STATUS "\t\"${test2}\" matches regular expression: ${regex}" )
else()
message( STATUS "\t\"${test2}\" DOES NOT match regular expression:
${regex}" )
endif()
message( STATUS )
message( STATUS "End matching ${test2} ..." )
--
Marek Vojtko
mail: marek.voj...@firaxis.com
phone: (+1) 410-229-2519
--
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
Re: [CMake] Variable Containing "MSVC" and MATCHES
On 2014-03-12 16:25, Marek Vojtko (Firaxis) wrote:
I know that MSVC is a CMake keyword and it is therefore not a good
idea to use the string "MSVC" as the value for any variable, e.g.
set( compiler "MSVC" ), because if you aren't careful and interpret
such a variable without surrounding it with quotes (e.g. ${compier}
rather than "${compiler}") you will get 0 or 1 depending on whether
you are using a Visual Studio generator or not. So far so good.
Actually, no. There is actually no difference between quoted and
unquoted expansion. (This is a long-standing issue that tends to trip up
even experienced people. The general consensus seems to be that we'd
like to do something about it, but it's difficult due to implementation
details.)
However, I was caught off guard by the fact that the MATCHES
directive (for regex matching) inside an IF() statement is apparently
interpreting the strings passed to it.
Right. Variables in if() are subject to implicit expansion. Quotes make
no difference.
Consider the following code:
if( "MSVC11" MATCHES "MSVC[0-9]+" )
message( STATUS "MSVC11 matches MSVC[0-9]+" )
endif()
If either "MSVC11" or "MSVC[0-9]+" is the name of a variable, it will be
expanded. (If the RHS is subject to expansion at all, which I would
suspect it is, but am not 100% sure without testing. Similarly if
implicit expansion is restricted to identifiers or not, which I suspect
it isn't. And yes, "MSVC[0-9]+" really is a valid name for a variable in
CMake :-(.)
(Note: *substrings* of arguments aren't implicitly expanded, but I
suspect you have a variable named "MSVC11".)
Putting either the string or the regex or both into variables doesn't help
either.
Yes and no. If you rewrite to *rely* on implicit expansion, it would
help. However, the result of an explicit expansion is still subject to
implicit expansion.
The only thing that prevents MSVC from being interpreted is putting
extra quotes into both the string and the regexp, i.e. "\"MSVC11\""
MATCHES "\"MSVC[0-9]+\"".
This is roughly how I usually deal with the issue. Note that the quote
itself isn't special, it's just that you don't have a variable named
'"MSVC11"'. You could equally write:
if("#MSVC11" MATCHES "#MSVC[0-9]+")
...or any other set of non-special characters used to reduce the
likelihood (e.g. autotools likes 'x').
If this is by design, i.e. not a bug, what are the reasons for this?
I believe this is so that you can write e.g. 'if(VAR STREQUAL "VALUE")',
which is arguably more natural. Unfortunately, both the LHS and RHS are
really just strings in both cases.
--
Matthew
--
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://www.cmake.org/mailman/listinfo/cmake
