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