[CMake] Building a Windows project in both 32- and 64-bit mode using the nmake generator.
We're trying to convert a project from using a very old hand-built makefile (the original version was written over 20 years ago!) to using cmake. We want to do the builds using command line nmake, not using Visual Studio project files. With our existing setup, to switch between 32- and 64- bit builds, we only need to change the option specified on the vcvarsall batch file and do a clean build. The tools figure out from the environment variables which build we're doing any everything works great. We've started our conversion by converting one of our smaller library files. All of the source files appear to compile correctly, but when we get to the link, we're getting the following error: Linking CXX shared library CMakeFiles\bin\rexxapi.dll msvcprtd.lib(MSVCP120D.dll) : fatal error LNK1112: module machine type 'x64' con flicts with target machine type 'X86' LINK Pass 1 failed. with 1112 NMAKE : fatal error U1077: 'C:\Program Files (x86)\CMake 2.8\bin\cmake.exe' : return code '0x' Stop. NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 12.0 \VC\BIN\amd64\nmake.exe' : return code '0x2' Stop. NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 12.0 \VC\BIN\amd64\nmake.exe' : return code '0x2' Stop. looking at the generated build.make file, I see that the option /machine:X86 appears on the link command. I tried manually deleting that option, but the error persisted. What do I need to do for cmake to generate the correct 64-bit logic...and equally as important, how do we switch between doing 32-bit and 64-bit builds when needed? And let me repeat, we do not want to use the Visual Studio generators...we want the nmake version. Rick -- 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] Building a Windows project in both 32- and 64-bit mode using the nmake generator.
On 01.05.2014 15:04, Rick McGuire wrote: With our existing setup, to switch between 32- and 64- bit builds, we only need to change the option specified on the vcvarsall batch file and do a clean build. The tools figure out from the environment variables which build we're doing any everything works great. Does the clean build involve removing the build directory or at least removing CMakeCache.txt/CMakeFiles? Otherwise CMake will keep using the cached compiler information from the initial configuration rather than querying the build environment again. 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] Building a Windows project in both 32- and 64-bit mode using the nmake generator.
clean build referred to our existing system, not the cmake conversion. For our current system, it is only necssary to nuke the build output directory. Figuring out the mechanics of doing a switching mode under cmake is something we'll deal with once we're able to get the different kinds of build working. Rick On Thu, May 1, 2014 at 9:09 AM, Nils Gladitz nilsglad...@gmail.com wrote: On 01.05.2014 15:04, Rick McGuire wrote: With our existing setup, to switch between 32- and 64- bit builds, we only need to change the option specified on the vcvarsall batch file and do a clean build. The tools figure out from the environment variables which build we're doing any everything works great. Does the clean build involve removing the build directory or at least removing CMakeCache.txt/CMakeFiles? Otherwise CMake will keep using the cached compiler information from the initial configuration rather than querying the build environment again. 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] Building a Windows project in both 32- and 64-bit mode using the nmake generator.
On 01.05.2014 15:54, Rick McGuire wrote: Is it possible to get cmake to check the actual compile/link commands when they are issued? I'd love to compare the cmake versions to our existing build to see if things are ending up the same. To a degree (response files on window limit the output in some cases); see below. Creating a minimal self-contained test case would not be easy. This is an open source project though, if you're willing to try checking it out. The svn url is svn http://svn.code.sf.net/p/oorexx/code-0/main/trunk I was able to build the project with these steps: - Open the VS2013 x64 Cross Tools Command Prompt - Add target_link_libraries(rexxapi ws2_32) to the end of CMakeLists.txt - Create a build directory in the source directory - Run cmake -G NMake Makefiles .. from the build directory - Run nmake VERBOSE=1 The command for the link this generates on my system is: C:\PROGRA~2\MICROS~2.0\VC\bin\X86_AM~1\link.exe /nologo @CMakeFiles\rexxapi.dir\objects1.rsp /out:..\CMakeFiles\bin\rexxapi.dll /implib:..\CMakeFiles\bin\rexxapi.lib /pdb:C:\Users\ngladitz\src\main\CMakeFiles\bin\rexxapi.pdb /dll /version:0.0 /machine:x64 /debug /INCREMENTAL ws2_32.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:..\CMakeFiles\bin\rexxapi.dll.intermediate.manifest ..\CMakeFiles\bin\rexxapi.dll.embed.manifest.res The link is successful. Some of the project's setup looks unorthodox. Specifically: - outputting binaries in the sources directory rather than the build directory (this might break parallel build directories or being able to purge build directories since they would not contain all artifacts) - using a directory called CMakeFiles for the output (which in in source-tree builds would belong to cmake and should not be used by the project) - The two platform dependent add_library() calls could be merged into a single call that uses a list variable for the platform specific sources. The redundant listing looks error prone. 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] Building a Windows project in both 32- and 64-bit mode using the nmake generator.
On 01.05.2014 16:57, Rick McGuire wrote: I was able to build the project with these steps: - Open the VS2013 x64 Cross Tools Command Prompt This is not something I'm familiar with...where do I find this? Also, if this is something only available if you have the full Visual Studio installed, that is a problem. We really need to have this project buildable using the free download version of the compiler. It is a shortcut to vcvarsall.bat (with x86_amd64 as a parameter) in the windows start menu as installed (on my system) by the VS Express 2013 for Desktop (free edition). - Add target_link_libraries(rexxapi ws2_32) to the end of CMakeLists.txt what does the ws2_32 do? ws2_32 is the windows' winsock2 library. Without it I got unresolved symbols to winsock calls made by the project. The existing comment in CMakeLists.txt about missing windows libraries implies that this is a known issue. - Create a build directory in the source directory to you mean at the trunk root, or some other location? Do I need to copy the CMakeLists.txt or any other files there? I created an empty directory called build inside the directory called main. I did not copy any files there. CMake will fill the directory when invoked from within. 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] file INSTALL cannot set modification time on
Hello,
I have a few Visual Studio projects that I set a post-build event in Visual
Studio to copy the DLLs, LIBs and a few other files up into a directory used
for development. I do this by running the following custom command:
add_custom_command(TARGET ${PROJECT_NAME} POST_BUILD COMMAND
${CMAKE_COMMAND} -D
BUILD_TYPE:STRING=\$(Configuration)
-D
CMAKE_INSTALL_LOCAL_ONLY:STRING=TRUE
-D
CMAKE_INSTALL_PREFIX:STRING=${ARA_DIR}
-D
COMPONENT:STRING=development
-P
${PROJECT_BINARY_DIR}/cmake_install.cmake VERBATIM)
I can guarantee you that all of the paths are correct and that this used to
work no problem. Now, every now and then I get the following error:
12PostBuildEvent:
12 -- Install configuration: Debug
12 -- Install component: development
12 -- Installing: C:/projects/AraFramework/bin/AraOpenGLd.dll
12 CMake Error at cmake_install.cmake:64 (FILE):
12file INSTALL cannot set modification time on
12C:/projects/AraFramework/bin/AraOpenGLd.dll
12
12
12C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets
(113,5): error MSB3073: The command setlocal
12C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets
(113,5): error MSB3073: C:\projects\CMake\2.8\bin\cmake.exe -D BUILD_TYPE:STRING
=Debug -D CMAKE_INSTALL_LOCAL_ONLY:STRING=TRUE -D CMAKE_INSTALL_PREFIX:STRING=C:
/projects/AraFramework -D COMPONENT:STRING=development -P C:/projects/AraFramewo
rk/src/vc10-build/AraOpenGL/cmake_install.cmake
12C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets
(113,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd
12C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets
(113,5): error MSB3073: :cmEnd
12C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets
(113,5): error MSB3073: endlocal call :cmErrorLevel %errorlevel% goto :cmDon
e
12C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets
(113,5): error MSB3073: :cmErrorLevel
12C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets
(113,5): error MSB3073: exit /b %1
12C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets
(113,5): error MSB3073: :cmDone
12C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets
(113,5): error MSB3073: if %errorlevel% neq 0 goto :VCEnd
12C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets
(113,5): error MSB3073: :VCEnd exited with code 1.
12
12Build FAILED.
This is on a specific project, but it is not always the same project and it
happens very randomly. If I build the solution multiple times, it will
eventually make it through everything, but I always have to build the solution
multiple times. Does anyone know why this would be happening and if there is
something I could do to prevent it?
Thank You,
Eric
I am a fortunate man. Whenever I make a mistake, other people are sure to
notice it. -- The Analects, Confucius
--
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] file INSTALL cannot set modification time on
On 01.05.2014 18:32, Eric Clark wrote: 12PostBuildEvent: 12 -- Install configuration: Debug 12 -- Install component: development 12 -- Installing: C:/projects/AraFramework/bin/AraOpenGLd.dll 12 CMake Error at cmake_install.cmake:64 (FILE): 12file INSTALL cannot set modification time on 12 C:/projects/AraFramework/bin/AraOpenGLd.dll 12 12 I used to have similar issues. In my case the install was executed by a test that due to an issue with CTest was running in parallel with other tests that were using input files of the install(). Is it possible that other commands run in parallel that may have the input file open at the same time? 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] file INSTALL cannot set modification time on
Well, that is what I was thinking, so I turned off the /MP option and that did not help. The next thing that I was going to try was to set the number of parallel project builds to 1 instead of the default 8. If this works, it would seem like the post-build step is not part of the build of that project or something because I have already checked that dependencies are all correct. Thanks, Eric From: Nils Gladitz [mailto:nilsglad...@gmail.com] Sent: Thursday, May 01, 2014 11:52 AM To: Eric Clark; cmake@cmake.org Subject: Re: [CMake] file INSTALL cannot set modification time on On 01.05.2014 18:32, Eric Clark wrote: 12PostBuildEvent: 12 -- Install configuration: Debug 12 -- Install component: development 12 -- Installing: C:/projects/AraFramework/bin/AraOpenGLd.dll 12 CMake Error at cmake_install.cmake:64 (FILE): 12file INSTALL cannot set modification time on 12C:/projects/AraFramework/bin/AraOpenGLd.dll 12 12 I used to have similar issues. In my case the install was executed by a test that due to an issue with CTest was running in parallel with other tests that were using input files of the install(). Is it possible that other commands run in parallel that may have the input file open at the same time? 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] cmake 2.8.12.2 fails on AIX 6.1 with ld: target noipath not found
Hello I installed cmake 2.8.12.2 on AIX 6.1 with the intention of building MySQL. The build fails so I tried to cmake the simplest test program, and I get the same failure. The error is ld: target noipath not found It seems to me that noipath is a directive to the linker, so the linker should not be looking for a target called noipath. Can anyone help with this? Thanks Graham Russell Details: I installed the cmake-2.8.12.2-AIX-powerpc.tar.gz file. The AIX version is AIX 6100-03-03-0943. I created a folder CMake/Tests/Tutorial containing the first step in http://www.cmake.org/cmake/help/cmake_tutorial.html: CMakeLists.txt tutorial.cxx Then ran cmake as below: pvm-vangogh-94:grussell [602] bin/cmake . -- The C compiler identification is GNU 4.4.4 -- The CXX compiler identification is GNU 4.4.4 -- Check for working C compiler: /usr/local/bin/gcc -- Check for working C compiler: /usr/local/bin/gcc -- broken CMake Error at /mnt/research/grussell/cmake-2.8.12.2-AIX-powerpc/share/cmake-2.8/Modules/CMakeTestCCompiler.cm ake:61 (message): The C compiler /usr/local/bin/gcc is not able to compile a simple test program. It fails with the following output: Change Dir: /mnt/research/grussell/CMake/Tests/Tutorial/CMakeFiles/CMakeTmp Run Build Command:/bin/gmake cmTryCompileExec680887608/fast /bin/gmake -f CMakeFiles/cmTryCompileExec680887608.dir/build.make CMakeFiles/cmTryCompileExec680887608.dir/build gmake[1]: Entering directory `/mnt/research/grussell/CMake/Tests/Tutorial/CMakeFiles/CMakeTmp' /mnt/research/grussell/cmake-2.8.12.2-AIX-powerpc/bin/cmake -E cmake_progress_report /mnt/research/grussell/CMake/Tests/Tutorial/CMakeFiles/CMakeTmp/CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec680887608.dir/testCCompiler.c.o /usr/local/bin/gcc -o CMakeFiles/cmTryCompileExec680887608.dir/testCCompiler.c.o -c /mnt/research/grussell/CMake/Tests/Tutorial/CMakeFiles/CMakeTmp/testCCompiler.c Log files: pvm-vangogh-94:grussell [607] cat CMakeOutput.log The system is: AIX - 1 - powerpc Compiling the C compiler identification source file CMakeCCompilerId.c succeeded. Compiler: /usr/local/bin/gcc Build flags: Id flags: The output was: 0 Compilation of the C compiler identification source CMakeCCompilerId.c produced a.out The C compiler identification is GNU, found in /mnt/research/grussell/CMake/Tests/Tutorial/CMakeFiles/2.8.12. 2/CompilerIdC/a.out Compiling the CXX compiler identification source file CMakeCXXCompilerId.cpp succeeded. Compiler: /usr/local/bin/c++ Build flags: Id flags: The output was: 0 Compilation of the CXX compiler identification source CMakeCXXCompilerId.cpp produced a.out The CXX compiler identification is GNU, found in /mnt/research/grussell/CMake/Tests/Tutorial/CMakeFiles/2.8.1 2.2/CompilerIdCXX/a.out pvm-vangogh-94:grussell [608] cat CMakeError.log Determining if the C compiler works failed with the following output: Change Dir: /mnt/research/grussell/CMake/Tests/Tutorial/CMakeFiles/CMakeTmp Run Build Command:/bin/gmake cmTryCompileExec680887608/fast /bin/gmake -f CMakeFiles/cmTryCompileExec680887608.dir/build.make CMakeFiles/cmTryCompileExec680887608.dir/bui ld gmake[1]: Entering directory `/mnt/research/grussell/CMake/Tests/Tutorial/CMakeFiles/CMakeTmp' /mnt/research/grussell/cmake-2.8.12.2-AIX-powerpc/bin/cmake -E cmake_progress_report /mnt/research/grussell/CM ake/Tests/Tutorial/CMakeFiles/CMakeTmp/CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec680887608.dir/testCCompiler.c.o /usr/local/bin/gcc-o CMakeFiles/cmTryCompileExec680887608.dir/testCCompiler.c.o -c /mnt/research/grussel l/CMake/Tests/Tutorial/CMakeFiles/CMakeTmp/testCCompiler.c Linking C executable cmTryCompileExec680887608 /mnt/research/grussell/cmake-2.8.12.2-AIX-powerpc/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec68 0887608.dir/link.txt --verbose=1 /usr/local/bin/gcc CMakeFiles/cmTryCompileExec680887608.dir/testCCompiler.c.o -o cmTryCompileExec680887 608 -Wl,-brtl,-bnoipath,-bexpall -Wl,-blibpath:/usr/lib:/lib /usr/local/lib/gcc/powerpc-ibm-aix6.1.0.0/4.4.4/../../../../powerpc-ibm-aix6.1.0.0/bin/ld: target noipath not found collect2: ld returned 1 exit status gmake[1]: Leaving directory `/mnt/research/grussell/CMake/Tests/Tutorial/CMakeFiles/CMakeTmp' gmake[1]: *** [cmTryCompileExec680887608] Error 1 gmake: *** [cmTryCompileExec680887608/fast] Error 2 -- 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
Re: [CMake] file INSTALL cannot set modification time on
On 01.05.2014 19:00, Eric Clark wrote: Well, that is what I was thinking, so I turned off the /MP option and that did not help. The next thing that I was going to try was to set the number of parallel project builds to 1 instead of the default 8. If this works, it would seem like the post-build step is not part of the build of that project or something because I have already checked that dependencies are all correct. What about virus scanners or similar? As a post build event a scanner may be still busy checking the freshly created file perhaps? 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] file INSTALL cannot set modification time on
That is an idea, except that this just happened again with the parallel project builds turned down to 1 and the /MP option not set. And the file that was being copied was not even created by the build. Instead, the file is one that is being copied from another location: QtSql4.dll. This particular file is only a dependency of the project that just finished building prior to the post build step and it is not built by the solution, it is only copied over. Eric From: Nils Gladitz [mailto:nilsglad...@gmail.com] Sent: Thursday, May 01, 2014 12:04 PM To: Eric Clark; cmake@cmake.org Subject: Re: [CMake] file INSTALL cannot set modification time on On 01.05.2014 19:00, Eric Clark wrote: Well, that is what I was thinking, so I turned off the /MP option and that did not help. The next thing that I was going to try was to set the number of parallel project builds to 1 instead of the default 8. If this works, it would seem like the post-build step is not part of the build of that project or something because I have already checked that dependencies are all correct. What about virus scanners or similar? As a post build event a scanner may be still busy checking the freshly created file perhaps? 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] cmake 2.8.12.2 fails on AIX 6.1 with ld: target noipath not found
On 5/1/2014 12:30 PM, Graham Russell wrote:
Hello
I installed cmake 2.8.12.2 on AIX 6.1 with the intention of building
MySQL. The build fails so I tried to cmake the simplest test program,
and I get the same failure.
The error is “ld: target noipath not found”
It seems to me that “noipath” is a directive to the linker, so the
linker should not be looking for a target called noipath.
Can anyone help with this?
Thanks
Graham Russell
This is not a CMake problem. Your compiler install is bad.
CMake is testing the compile of a very simple .c file and it is not work.
I suspect that a simple program like this:
int main() { return 0;}
will not compile and link with the /usr/local/bin/gcc on your system.
Create the above file and try to compile it without cmake and just gcc.
It should get the same error. I would suggest that you reinstall gcc
on the machine.
-Bill
--
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] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
I thought they probably were. My question was really if the behaviour that results from that was desirable. I can't see any reason why they should be cached as they aren't user configurable variables. Would it break anything badly if they were not stored in the cache ? It would result in more consistent behaviour IMHO. -- Glenn On 28 April 2014 19:33, Matthew Woehlke mw_tr...@users.sourceforge.netwrote: On 2014-04-23 14:18, Glenn Coombs wrote: Are the [Project name]_SOURCE_DIR variables being automatically stored in the cmake cache? Running 'grep _SOURCE_DIR CMakeCache.txt' would answer this question. (And yes, they are.) -- 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 -- 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] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
I thought they probably were. My question was really if the behaviour that results from that was desirable. I can't see any reason why they should be cached as they aren't user configurable variables. Would it break anything badly if they were not stored in the cache ? It would result in more consistent behaviour IMHO. Executing cmake . would fail in the bin folder if it had no way to know where the source folder is. John -- 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] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
What I am saying is that project(foo) should internally execute the equivalent of set(foo_SOURCE_DIR /path/to/source) rather than set(foo /path/to/source CACHE STRING). That way it would fail on every run if you referenced a project source directory variable before you had done the add_subdirectory() for that project. Currently in that situation it fails the first time you run cmake but works as expected on subsequent runs of cmake, which I think is odd behaviour. On 1 May 2014 18:35, John Drescher dresche...@gmail.com wrote: I thought they probably were. My question was really if the behaviour that results from that was desirable. I can't see any reason why they should be cached as they aren't user configurable variables. Would it break anything badly if they were not stored in the cache ? It would result in more consistent behaviour IMHO. Executing cmake . would fail in the bin folder if it had no way to know where the source folder is. John -- 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] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
On Thu, May 1, 2014 at 1:54 PM, Glenn Coombs glenn.coo...@gmail.com wrote: What I am saying is that project(foo) should internally execute the equivalent of set(foo_SOURCE_DIR /path/to/source) rather than set(foo /path/to/source CACHE STRING). That way it would fail on every run if you referenced a project source directory variable before you had done the add_subdirectory() for that project. Currently in that situation it fails the first time you run cmake but works as expected on subsequent runs of cmake, which I think is odd behaviour. I am saying making this change to not cache the source folder would break cmake binfolder and cmake --build buildfolder and several other commands that have worked this way for years. John -- 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] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
On 2014-05-01 13:35, John Drescher wrote: I thought they probably were. My question was really if the behaviour that results from that was desirable. I can't see any reason why they should be cached as they aren't user configurable variables. Would it break anything badly if they were not stored in the cache ? It would result in more consistent behaviour IMHO. Executing cmake . would fail in the bin folder if it had no way to know where the source folder is. If CMAKE_BINARY_DIR were not cached, yes. But I don't think not caching that is being suggested. It's not clear to me why the *per-project* flavors need to be cached? -- 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
Re: [CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
On Thu, May 1, 2014 at 2:16 PM, Matthew Woehlke mw_tr...@users.sourceforge.net wrote: On 2014-05-01 13:35, John Drescher wrote: I thought they probably were. My question was really if the behaviour that results from that was desirable. I can't see any reason why they should be cached as they aren't user configurable variables. Would it break anything badly if they were not stored in the cache ? It would result in more consistent behaviour IMHO. Executing cmake . would fail in the bin folder if it had no way to know where the source folder is. If CMAKE_BINARY_DIR were not cached, yes. But I don't think not caching that is being suggested. It's not clear to me why the *per-project* flavors need to be cached? I see now. Sorry for the noise.. John -- 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] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
On 01.05.2014 20:16, Matthew Woehlke wrote: If CMAKE_BINARY_DIR were not cached, yes. But I don't think not caching that is being suggested. It's not clear to me why the *per-project* flavors need to be cached? If they were regular instead of cache variables they would have scopes. I guess this would break any project that currently referred to their sub- or sibling projects with those variables. 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] file INSTALL cannot set modification time on
I turned off all virus and spam software and that did not do it either. I am lost here, I have no idea what to do anymore. Any help from anyone would be greatly appreciated! Thanks, Eric From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Eric Clark Sent: Thursday, May 01, 2014 12:07 PM To: Nils Gladitz; cmake@cmake.org Subject: Re: [CMake] file INSTALL cannot set modification time on That is an idea, except that this just happened again with the parallel project builds turned down to 1 and the /MP option not set. And the file that was being copied was not even created by the build. Instead, the file is one that is being copied from another location: QtSql4.dll. This particular file is only a dependency of the project that just finished building prior to the post build step and it is not built by the solution, it is only copied over. Eric From: Nils Gladitz [mailto:nilsglad...@gmail.com]mailto:[mailto:nilsglad...@gmail.com] Sent: Thursday, May 01, 2014 12:04 PM To: Eric Clark; cmake@cmake.orgmailto:cmake@cmake.org Subject: Re: [CMake] file INSTALL cannot set modification time on On 01.05.2014 19:00, Eric Clark wrote: Well, that is what I was thinking, so I turned off the /MP option and that did not help. The next thing that I was going to try was to set the number of parallel project builds to 1 instead of the default 8. If this works, it would seem like the post-build step is not part of the build of that project or something because I have already checked that dependencies are all correct. What about virus scanners or similar? As a post build event a scanner may be still busy checking the freshly created file perhaps? 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] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
On Thu, May 1, 2014 at 11:26 AM, Nils Gladitz nilsglad...@gmail.com wrote: On 01.05.2014 20:16, Matthew Woehlke wrote: If CMAKE_BINARY_DIR were not cached, yes. But I don't think not caching that is being suggested. It's not clear to me why the *per-project* flavors need to be cached? If they were regular instead of cache variables they would have scopes. I guess this would break any project that currently referred to their sub- or sibling projects with those variables. Ya; promotion to global namespace via addition to cache is a good reason to have them cached But, it's not that you have a dynamic build structure that changes often? It's just that you're trying to reference a variable before it exists; and there's ways around that like set a CMAKE_PASS_2 variable or something to make sure that everything is done the next time... and it fails on a first-run .. but then it doesn't fail, so it's hard to track down where the error was? maybe cmake --trace ? -- 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] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
On 2014-05-01 14:26, Nils Gladitz wrote: On 01.05.2014 20:16, Matthew Woehlke wrote: If CMAKE_BINARY_DIR were not cached, yes. But I don't think not caching that is being suggested. It's not clear to me why the *per-project* flavors need to be cached? If they were regular instead of cache variables they would have scopes. I guess this would break any project that currently referred to their sub- or sibling projects with those variables. Hmm... that's a good point. I suspect project() could work around the scope at least by arranging to set them in the root scope, but there might be other, related issues that could arise. Nuts :-). -- 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
Re: [CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
Okay, I think I understand what you're saying. Variables set in a CMakeLists.txt file added by add_subdirectory are only visible in that CMakeLists.txt and any further ones it adds via add_subdirectory. The higher level CMakeLists.txt files would not have the necessary visibility, hence the need to cache the project source directory variable. To make it behave consistently it would be necessary for cmake to be able to set a variable in the scope of the top level CMakeLists.txt. Similar to the PARENT_SCOPE that the set() command already has, something like set(foo_SOURCE_PROJECT path/to/source ROOT_SCOPE). I suspect that the reason cmake is caching these variable is because the set() command doesn't have a ROOT_SCOPE ability and using cache variables was the easiest way to simulate that. And we have to live with the unfortunate side effect that the cached variables don't exist on the first run but do on subsequent runs. On 1 May 2014 19:00, John Drescher dresche...@gmail.com wrote: On Thu, May 1, 2014 at 1:54 PM, Glenn Coombs glenn.coo...@gmail.com wrote: What I am saying is that project(foo) should internally execute the equivalent of set(foo_SOURCE_DIR /path/to/source) rather than set(foo /path/to/source CACHE STRING). That way it would fail on every run if you referenced a project source directory variable before you had done the add_subdirectory() for that project. Currently in that situation it fails the first time you run cmake but works as expected on subsequent runs of cmake, which I think is odd behaviour. I am saying making this change to not cache the source folder would break cmake binfolder and cmake --build buildfolder and several other commands that have worked this way for years. John -- 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] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
On 01.05.2014 20:38, Glenn Coombs wrote: Okay, I think I understand what you're saying. Variables set in a CMakeLists.txt file added by add_subdirectory are only visible in that CMakeLists.txt and any further ones it adds via add_subdirectory. The higher level CMakeLists.txt files would not have the necessary visibility, hence the need to cache the project source directory variable. To make it behave consistently it would be necessary for cmake to be able to set a variable in the scope of the top level CMakeLists.txt. Similar to the PARENT_SCOPE that the set() command already has, something like set(foo_SOURCE_PROJECT path/to/source ROOT_SCOPE). I suspect that the reason cmake is caching these variable is because the set() command doesn't have a ROOT_SCOPE ability and using cache variables was the easiest way to simulate that. And we have to live with the unfortunate side effect that the cached variables don't exist on the first run but do on subsequent runs. I don't think it would be sufficient to set it in the root scope either since I think each scope has its own copy of the variable. It would have to be set for all scopes between the root and the current scope. 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] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
Ugh ! It gets messier. I'm beginning to understand why it is the way it is. The cmake developers have probably already been round this loop and decided it wasn't worth the effort :-) On 1 May 2014 19:41, Nils Gladitz nilsglad...@gmail.com wrote: On 01.05.2014 20:38, Glenn Coombs wrote: Okay, I think I understand what you're saying. Variables set in a CMakeLists.txt file added by add_subdirectory are only visible in that CMakeLists.txt and any further ones it adds via add_subdirectory. The higher level CMakeLists.txt files would not have the necessary visibility, hence the need to cache the project source directory variable. To make it behave consistently it would be necessary for cmake to be able to set a variable in the scope of the top level CMakeLists.txt. Similar to the PARENT_SCOPE that the set() command already has, something like set(foo_SOURCE_PROJECT path/to/source ROOT_SCOPE). I suspect that the reason cmake is caching these variable is because the set() command doesn't have a ROOT_SCOPE ability and using cache variables was the easiest way to simulate that. And we have to live with the unfortunate side effect that the cached variables don't exist on the first run but do on subsequent runs. I don't think it would be sufficient to set it in the root scope either since I think each scope has its own copy of the variable. It would have to be set for all scopes between the root and the current scope. 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] cmake 2.8.12.2 fails on AIX 6.1 with ld: target noipath not found
Thanks for the response, Bill.
I confirmed that the compiler install works fine:
pvm-vangogh-94:grussell [625] /usr/local/bin/gcc hello.c -o hello
pvm-vangogh-94:grussell [626] ./hello Hello World!
I also tested it with your simple program and it also compiles OK and runs.
I think the problem lies in the options that CMake uses to test the AIX compile
environment.
Thanks
Graham Russell
-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Bill Hoffman
Sent: Thursday, May 01, 2014 10:17 AM
To: cmake@cmake.org
Subject: Re: [CMake] cmake 2.8.12.2 fails on AIX 6.1 with ld: target noipath
not found
On 5/1/2014 12:30 PM, Graham Russell wrote:
Hello
I installed cmake 2.8.12.2 on AIX 6.1 with the intention of building
MySQL. The build fails so I tried to cmake the simplest test program,
and I get the same failure.
The error is ld: target noipath not found
It seems to me that noipath is a directive to the linker, so the
linker should not be looking for a target called noipath.
Can anyone help with this?
Thanks
Graham Russell
This is not a CMake problem. Your compiler install is bad.
CMake is testing the compile of a very simple .c file and it is not work.
I suspect that a simple program like this:
int main() { return 0;}
will not compile and link with the /usr/local/bin/gcc on your system.
Create the above file and try to compile it without cmake and just gcc.
It should get the same error. I would suggest that you reinstall gcc on the
machine.
-Bill
--
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
--
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] cmake 2.8.12.2 fails on AIX 6.1 with ld: target noipath not found
On 5/1/2014 4:04 PM, Graham Russell wrote:
Thanks for the response, Bill.
I confirmed that the compiler install works fine:
pvm-vangogh-94:grussell [625] /usr/local/bin/gcc hello.c -o hello
pvm-vangogh-94:grussell [626] ./hello Hello World!
I also tested it with your simple program and it also compiles OK and runs.
I think the problem lies in the options that CMake uses to test the AIX compile
environment.
Thanks
Graham Russell
OK, from the log you sent, we can see that CMake is passing some stuff
to the linker:
/usr/local/bin/gcc
CMakeFiles/cmTryCompileExec680887608.dir/testCCompiler.c.o -o
cmTryCompileExec680887608 -Wl,-brtl,-bnoipath,-bexpall
-Wl,-blibpath:/usr/lib:/lib
I think the problem is that you are using the GNU linker, and CMake
seems to be expecting the AIX linker to be used even with gcc.
You can see this is the linker used:
/usr/local/lib/gcc/powerpc-ibm-aix6.1.0.0/4.4.4/../../../../powerpc-ibm-aix6.1.0.0/bin/ld:
Which is the GNU linker and not the AIX linker which supports and needs
that flag.
You should be able to change this in Modules/AIX-GNU.cmake
which has this:
set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS
-Wl,-brtl,-bnoipath,-bexpall) # +s, flag for exe link to use shared lib
That should get you going. I will think about a solution that can be
incorporated into CMake. Would you be willing to run a nightly
dashboard with this configuration so we can test it over time?
Thanks.
-Bill
--
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] cmake 2.8.12.2 fails on AIX 6.1 with ld: target noipath not found
Seems like there are 2 choices for a solution:
1. Change CMake so it uses the IBM linker instead of the GNU linker. What
settings would I need to change in the cmake files to try this?
2. Change the linker options so they will work for the GNU linker.
I tried option #2 by removing -bnoipath from the Modules/AIX-GNU.cmake file.
This enabled cmake to run successfully on test files and on the MySQL package.
However, my ultimate aim being to build MySQL, the make did run into errors
subsequently, so I would like to try option #1 also. I am interested if you
have an opinion as to whether option #1 or option #2 would give me a better
shot at building MySQL.
Further to your question Would you be willing to run a nightly
dashboard with this configuration so we can test it over time?
I would be willing, but need to know how to do this and what it involves.
Thanks
Graham Russell
-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Bill Hoffman
Sent: Thursday, May 01, 2014 1:33 PM
To: cmake@cmake.org
Subject: Re: [CMake] cmake 2.8.12.2 fails on AIX 6.1 with ld: target noipath
not found
On 5/1/2014 4:04 PM, Graham Russell wrote:
Thanks for the response, Bill.
I confirmed that the compiler install works fine:
pvm-vangogh-94:grussell [625] /usr/local/bin/gcc hello.c -o hello
pvm-vangogh-94:grussell [626] ./hello Hello World!
I also tested it with your simple program and it also compiles OK and runs.
I think the problem lies in the options that CMake uses to test the AIX
compile environment.
Thanks
Graham Russell
OK, from the log you sent, we can see that CMake is passing some stuff to the
linker:
/usr/local/bin/gcc
CMakeFiles/cmTryCompileExec680887608.dir/testCCompiler.c.o -o
cmTryCompileExec680887608 -Wl,-brtl,-bnoipath,-bexpall
-Wl,-blibpath:/usr/lib:/lib
I think the problem is that you are using the GNU linker, and CMake seems to be
expecting the AIX linker to be used even with gcc.
You can see this is the linker used:
/usr/local/lib/gcc/powerpc-ibm-aix6.1.0.0/4.4.4/../../../../powerpc-ibm-aix6.1.0.0/bin/ld:
Which is the GNU linker and not the AIX linker which supports and needs that
flag.
You should be able to change this in Modules/AIX-GNU.cmake
which has this:
set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS
-Wl,-brtl,-bnoipath,-bexpall) # +s, flag for exe link to use shared lib
That should get you going. I will think about a solution that can be
incorporated into CMake. Would you be willing to run a nightly
dashboard with this configuration so we can test it over time?
Thanks.
-Bill
--
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
--
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] cmake 2.8.12.2 fails on AIX 6.1 with ld: target noipath not found
On Thu, May 1, 2014 at 6:35 PM, Graham Russell gruss...@cheetah.com wrote:
Seems like there are 2 choices for a solution:
1. Change CMake so it uses the IBM linker instead of the GNU linker.
What settings would I need to change in the cmake files to try this?
This is not really an option. CMake can not choose the linker for the
compiler. You would have to rebuild gcc with the option to use the native
linker.
2. Change the linker options so they will work for the GNU linker.
I tried option #2 by removing -bnoipath from the Modules/AIX-GNU.cmake
file. This enabled cmake to run successfully on test files and on the
MySQL package.
Yes, that would be the way to do it. However, we have to somehow tell the
difference between a gcc configured to use the native linker and one
configured to use the GNU linker and pick the flags accordingly.
However, my ultimate aim being to build MySQL, the make did run into
errors subsequently, so I would like to try option #1 also. I am
interested if you have an opinion as to whether option #1 or option #2
would give me a better shot at building MySQL.
I think you have to deal with those errors or rebuild gcc with the native
linker, or use the native compilers.
Further to your question Would you be willing to run a nightly
dashboard with this configuration so we can test it over time?
I would be willing, but need to know how to do this and what it involves.
It involves setting up a cronjob on your machine that runs once a day and
pulls from the cmake repository, builds cmake, and runs the tests, then
sends the results to CDash. If we get to that point I can send pretty
simple instructions.
Thanks.
-Bill
Thanks
Graham Russell
-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Bill Hoffman
Sent: Thursday, May 01, 2014 1:33 PM
To: cmake@cmake.org
Subject: Re: [CMake] cmake 2.8.12.2 fails on AIX 6.1 with ld: target
noipath not found
On 5/1/2014 4:04 PM, Graham Russell wrote:
Thanks for the response, Bill.
I confirmed that the compiler install works fine:
pvm-vangogh-94:grussell [625] /usr/local/bin/gcc hello.c -o hello
pvm-vangogh-94:grussell [626] ./hello Hello World!
I also tested it with your simple program and it also compiles OK and
runs.
I think the problem lies in the options that CMake uses to test the AIX
compile environment.
Thanks
Graham Russell
OK, from the log you sent, we can see that CMake is passing some stuff to
the linker:
/usr/local/bin/gcc
CMakeFiles/cmTryCompileExec680887608.dir/testCCompiler.c.o -o
cmTryCompileExec680887608 -Wl,-brtl,-bnoipath,-bexpall
-Wl,-blibpath:/usr/lib:/lib
I think the problem is that you are using the GNU linker, and CMake seems
to be expecting the AIX linker to be used even with gcc.
You can see this is the linker used:
/usr/local/lib/gcc/powerpc-ibm-aix6.1.0.0/4.4.4/../../../../powerpc-ibm-aix6.1.0.0/bin/ld:
Which is the GNU linker and not the AIX linker which supports and needs
that flag.
You should be able to change this in Modules/AIX-GNU.cmake
which has this:
set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS
-Wl,-brtl,-bnoipath,-bexpall) # +s, flag for exe link to use shared lib
That should get you going. I will think about a solution that can be
incorporated into CMake. Would you be willing to run a nightly
dashboard with this configuration so we can test it over time?
Thanks.
-Bill
--
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
--
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
--
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:
[Cmake-commits] CMake branch, next, updated. v3.0.0-rc4-2653-ge275027
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via e27502756f8dadb524c0198c7ab5ac27355fcf75 (commit)
via 1dda0f4778e77ea9a78502f83691273901b0ce0f (commit)
from 69b5d0f0b61912a4641ab95d130df790e33dd75b (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e27502756f8dadb524c0198c7ab5ac27355fcf75
commit e27502756f8dadb524c0198c7ab5ac27355fcf75
Merge: 69b5d0f 1dda0f4
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu May 1 08:56:14 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu May 1 08:56:14 2014 -0400
Merge topic 'dont-rewrite-moc-parameter-file' into next
1dda0f47 Tests: Fix Qt4Targets test inner project name
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1dda0f4778e77ea9a78502f83691273901b0ce0f
commit 1dda0f4778e77ea9a78502f83691273901b0ce0f
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu May 1 08:54:29 2014 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu May 1 08:54:29 2014 -0400
Tests: Fix Qt4Targets test inner project name
The try_compile command third argument must be the value given to
the project() command in the IncrmentalMoc/CMakeLists.txt file.
While at it, extend the error message to include the try_compile
output to make debugging easier.
diff --git a/Tests/Qt4Targets/CMakeLists.txt b/Tests/Qt4Targets/CMakeLists.txt
index 3670746..ae0a02b 100644
--- a/Tests/Qt4Targets/CMakeLists.txt
+++ b/Tests/Qt4Targets/CMakeLists.txt
@@ -42,11 +42,16 @@ macro(test_incremental def)
try_compile(RESULT
${CMAKE_CURRENT_BINARY_DIR}/IncrementalMocBuild_${def}
${CMAKE_CURRENT_SOURCE_DIR}/IncrementalMoc
-IncrementalMoc_${def}
-CMAKE_FLAGS -D${def}=0
-DQT_QMAKE_EXECUTABLE:FILEPATH=${QT_QMAKE_EXECUTABLE})
+IncrementalMoc
+CMAKE_FLAGS -D${def}=0
-DQT_QMAKE_EXECUTABLE:FILEPATH=${QT_QMAKE_EXECUTABLE}
+OUTPUT_VARIABLE output
+)
file(TIMESTAMP
${CMAKE_CURRENT_BINARY_DIR}/IncrementalMocBuild_${def}/moc_foo.cpp
tsvar_before ${timeformat})
if (NOT tsvar_before)
-message(SEND_ERROR Unable to read timestamp from moc file from first
build with -D${def}!)
+message(SEND_ERROR
+ Unable to read timestamp from moc file from first build with
-D${def}!\n
+ try_compile output:\n${output}
+ )
endif()
execute_process(COMMAND ${CMAKE_COMMAND} -E sleep 2) # Ensure that the
timestamp will change.
@@ -54,11 +59,16 @@ macro(test_incremental def)
try_compile(RESULT
${CMAKE_CURRENT_BINARY_DIR}/IncrementalMocBuild_${def}
${CMAKE_CURRENT_SOURCE_DIR}/IncrementalMoc
-IncrementalMoc_${def}
-CMAKE_FLAGS -D${def}=1
-DQT_QMAKE_EXECUTABLE:FILEPATH=${QT_QMAKE_EXECUTABLE})
+IncrementalMoc
+CMAKE_FLAGS -D${def}=1
-DQT_QMAKE_EXECUTABLE:FILEPATH=${QT_QMAKE_EXECUTABLE}
+OUTPUT_VARIABLE output
+)
file(TIMESTAMP
${CMAKE_CURRENT_BINARY_DIR}/IncrementalMocBuild_${def}/moc_foo.cpp
tsvar_after ${timeformat})
if (NOT tsvar_after)
-message(SEND_ERROR Unable to read timestamp from moc file from second
build!)
+message(SEND_ERROR
+ Unable to read timestamp from moc file from second build!\n
+ try_compile output:\n${output}
+ )
endif()
if (NOT tsvar_after GREATER tsvar_before)
---
Summary of changes:
Tests/Qt4Targets/CMakeLists.txt | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.0.0-rc4-2655-g53b1841
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 53b18413241a92196848c545747d4b15991ea4ff (commit) via 80209fdb7bfd2841bde81fdc8f61090a4eaba360 (commit) from e27502756f8dadb524c0198c7ab5ac27355fcf75 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=53b18413241a92196848c545747d4b15991ea4ff commit 53b18413241a92196848c545747d4b15991ea4ff Merge: e275027 80209fd Author: Brad King brad.k...@kitware.com AuthorDate: Thu May 1 09:03:40 2014 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu May 1 09:03:40 2014 -0400 Merge topic 'FindCUDA-cubin-fatbin' into next 80209fdb Help: Add notes for topic 'FindCUDA-cubin-fatbin' http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=80209fdb7bfd2841bde81fdc8f61090a4eaba360 commit 80209fdb7bfd2841bde81fdc8f61090a4eaba360 Author: Brad King brad.k...@kitware.com AuthorDate: Thu May 1 09:02:34 2014 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Thu May 1 09:02:34 2014 -0400 Help: Add notes for topic 'FindCUDA-cubin-fatbin' diff --git a/Help/release/dev/FindCUDA-cubin-fatbin.rst b/Help/release/dev/FindCUDA-cubin-fatbin.rst new file mode 100644 index 000..d44da8e --- /dev/null +++ b/Help/release/dev/FindCUDA-cubin-fatbin.rst @@ -0,0 +1,5 @@ +FindCUDA-cubin-fatbin +- + +* The :module:`FindCUDA` module learned to support ``fatbin`` and ``cubin`` + modules. --- Summary of changes: Help/release/dev/FindCUDA-cubin-fatbin.rst |5 + 1 file changed, 5 insertions(+) create mode 100644 Help/release/dev/FindCUDA-cubin-fatbin.rst hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.0.0-rc4-750-g556e3a2
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 556e3a257440f2dae6561fdebca63379bda8fed5 (commit) via c962c21c8581c6e79b8392822a02e7f718a3ac2e (commit) from 849d86922358b3ab368fbd2eb328affe6a5c608b (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=556e3a257440f2dae6561fdebca63379bda8fed5 commit 556e3a257440f2dae6561fdebca63379bda8fed5 Merge: 849d869 c962c21 Author: Brad King brad.k...@kitware.com AuthorDate: Thu May 1 09:11:14 2014 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu May 1 09:11:14 2014 -0400 Merge topic 'drop-release-on-ferrari' c962c21c Utilities/Release: Drop IRIX binary generation on ferrari --- Summary of changes: Utilities/Release/create-cmake-release.cmake |2 -- Utilities/Release/ferrari_sgi64_release.cmake | 16 Utilities/Release/ferrari_sgi_release.cmake | 11 --- 3 files changed, 29 deletions(-) delete mode 100644 Utilities/Release/ferrari_sgi64_release.cmake delete mode 100644 Utilities/Release/ferrari_sgi_release.cmake hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.0.0-rc4-752-g6482fba
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 6482fbaf70ac5e5fbbc79257af957c19b65a9e90 (commit) via 420280f32265eda0e24b2b11ab9d39491d9e8512 (commit) from 556e3a257440f2dae6561fdebca63379bda8fed5 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6482fbaf70ac5e5fbbc79257af957c19b65a9e90 commit 6482fbaf70ac5e5fbbc79257af957c19b65a9e90 Merge: 556e3a2 420280f Author: Brad King brad.k...@kitware.com AuthorDate: Thu May 1 09:11:18 2014 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu May 1 09:11:18 2014 -0400 Merge topic 'ExternalProject-verify-cmake-var' 420280f3 ExternalProject: Fix path to cmake in verify script --- Summary of changes: Modules/ExternalProject.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.0.0-rc4-755-gdc8505c
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via dc8505cad61dc5a9dc08b1d9ea2effe903ec240d (commit) via 80209fdb7bfd2841bde81fdc8f61090a4eaba360 (commit) via 231b30dbfbf31da8233552cc92568f81d044a767 (commit) from 6482fbaf70ac5e5fbbc79257af957c19b65a9e90 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dc8505cad61dc5a9dc08b1d9ea2effe903ec240d commit dc8505cad61dc5a9dc08b1d9ea2effe903ec240d Merge: 6482fba 80209fd Author: Brad King brad.k...@kitware.com AuthorDate: Thu May 1 09:11:21 2014 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu May 1 09:11:21 2014 -0400 Merge topic 'FindCUDA-cubin-fatbin' 80209fdb Help: Add notes for topic 'FindCUDA-cubin-fatbin' 231b30db FindCUDA: Add support for compilation to fatbin cubin modules --- Summary of changes: Help/release/dev/FindCUDA-cubin-fatbin.rst |5 ++ Modules/FindCUDA.cmake | 89 +++- 2 files changed, 65 insertions(+), 29 deletions(-) create mode 100644 Help/release/dev/FindCUDA-cubin-fatbin.rst hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.0.0-rc4-757-gecdc198
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via ecdc1985e3f404902849161f7f3fac08cda4c7ff (commit)
via 42e1cd137c0eff0297adaea5b34abca0da254eba (commit)
from dc8505cad61dc5a9dc08b1d9ea2effe903ec240d (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ecdc1985e3f404902849161f7f3fac08cda4c7ff
commit ecdc1985e3f404902849161f7f3fac08cda4c7ff
Merge: dc8505c 42e1cd1
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu May 1 09:11:23 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu May 1 09:11:23 2014 -0400
Merge topic 'file-generate-if-different'
42e1cd13 file(GENERATE): Only write the file if content is different.
---
Summary of changes:
Source/cmGeneratorExpressionEvaluationFile.cxx | 15 +++
Tests/RunCMake/File_Generate/RunCMakeTest.cmake| 27
.../WriteIfDifferent-result.txt} |0
.../WriteIfDifferent-stderr.txt} |0
.../RunCMake/File_Generate/WriteIfDifferent.cmake |5
5 files changed, 35 insertions(+), 12 deletions(-)
copy Tests/RunCMake/{CMP0022/CMP0022-WARN-empty-old-result.txt =
File_Generate/WriteIfDifferent-result.txt} (100%)
copy Tests/RunCMake/{CMP0022/CMP0022-NOWARN-exe-stderr.txt =
File_Generate/WriteIfDifferent-stderr.txt} (100%)
create mode 100644 Tests/RunCMake/File_Generate/WriteIfDifferent.cmake
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.0.0-rc4-2661-g78888e3
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 7e30c6e4758394daa69189ba669288d14613 (commit) via ecdc1985e3f404902849161f7f3fac08cda4c7ff (commit) via dc8505cad61dc5a9dc08b1d9ea2effe903ec240d (commit) via 6482fbaf70ac5e5fbbc79257af957c19b65a9e90 (commit) via 556e3a257440f2dae6561fdebca63379bda8fed5 (commit) via 849d86922358b3ab368fbd2eb328affe6a5c608b (commit) from 53b18413241a92196848c545747d4b15991ea4ff (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7e30c6e4758394daa69189ba669288d14613 commit 7e30c6e4758394daa69189ba669288d14613 Merge: 53b1841 ecdc198 Author: Brad King brad.k...@kitware.com AuthorDate: Thu May 1 09:12:36 2014 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Thu May 1 09:12:36 2014 -0400 Merge branch 'master' into next --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.0.0-rc4-2663-g6c97535
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 6c97535fb61124ebb22ec9cb675ecd9805409398 (commit)
via 4a5cf9645317d486d7fbddf666878ee302689141 (commit)
from 7e30c6e4758394daa69189ba669288d14613 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6c97535fb61124ebb22ec9cb675ecd9805409398
commit 6c97535fb61124ebb22ec9cb675ecd9805409398
Merge: 7e3 4a5cf96
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu May 1 09:24:06 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu May 1 09:24:06 2014 -0400
Merge topic 'ExternalData-missing-not-fatal' into next
4a5cf964 Help: Add notes for topic 'ExternalData-missing-not-fatal'
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4a5cf9645317d486d7fbddf666878ee302689141
commit 4a5cf9645317d486d7fbddf666878ee302689141
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu May 1 09:19:30 2014 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu May 1 09:22:30 2014 -0400
Help: Add notes for topic 'ExternalData-missing-not-fatal'
diff --git a/Help/release/dev/ExternalData-missing-not-fatal.rst
b/Help/release/dev/ExternalData-missing-not-fatal.rst
new file mode 100644
index 000..e9f1f04
--- /dev/null
+++ b/Help/release/dev/ExternalData-missing-not-fatal.rst
@@ -0,0 +1,8 @@
+ExternalData-missing-not-fatal
+--
+
+* The :module:`ExternalData` module learned to tolerate a ``DATA{}``
+ reference to a missing source file with a warning instead of
+ rejecting it with an error. This helps developers write new
+ ``DATA{}`` references to test reference outputs that have not
+ yet been created.
---
Summary of changes:
Help/release/dev/ExternalData-missing-not-fatal.rst |8
1 file changed, 8 insertions(+)
create mode 100644 Help/release/dev/ExternalData-missing-not-fatal.rst
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.0.0-rc4-2665-g43eed7f
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 43eed7fe11168d70f802cadc7c40a726da679774 (commit) via 145d653e5f9390a74bf1bcd095c7f054b34c2fa2 (commit) from 6c97535fb61124ebb22ec9cb675ecd9805409398 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=43eed7fe11168d70f802cadc7c40a726da679774 commit 43eed7fe11168d70f802cadc7c40a726da679774 Merge: 6c97535 145d653 Author: Brad King brad.k...@kitware.com AuthorDate: Thu May 1 09:28:48 2014 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu May 1 09:28:48 2014 -0400 Merge topic 'UseSWIG-guess_module_name' into next 145d653e Help: Add notes for topic 'UseSWIG-guess_module_name' http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=145d653e5f9390a74bf1bcd095c7f054b34c2fa2 commit 145d653e5f9390a74bf1bcd095c7f054b34c2fa2 Author: Brad King brad.k...@kitware.com AuthorDate: Thu May 1 09:27:16 2014 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Thu May 1 09:27:16 2014 -0400 Help: Add notes for topic 'UseSWIG-guess_module_name' diff --git a/Help/release/dev/UseSWIG-guess_module_name.rst b/Help/release/dev/UseSWIG-guess_module_name.rst new file mode 100644 index 000..c895046 --- /dev/null +++ b/Help/release/dev/UseSWIG-guess_module_name.rst @@ -0,0 +1,6 @@ +UseSWIG-guess_module_name +- + +* The :module:`UseSWIG` module learned to detect the module name + from ``.i`` source files if possible to avoid the need to set + the ``SWIG_MODULE_NAME`` source file property explicitly. --- Summary of changes: Help/release/dev/UseSWIG-guess_module_name.rst |6 ++ 1 file changed, 6 insertions(+) create mode 100644 Help/release/dev/UseSWIG-guess_module_name.rst hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.0.0-rc4-759-g33e0454
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 33e04542b1ef367f6e4a170986448b8bd9e90120 (commit) via c553d68798b277506efc361f70987c81fea55fec (commit) from ecdc1985e3f404902849161f7f3fac08cda4c7ff (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, release, updated. v3.0.0-rc4-12-gc553d68
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, release has been updated via c553d68798b277506efc361f70987c81fea55fec (commit) via 420280f32265eda0e24b2b11ab9d39491d9e8512 (commit) from c2f27dadac950e0cb7dff57ec29035529f6bc90d (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - --- Summary of changes: Modules/ExternalProject.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.0.0-rc4-2668-g4a6a522
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 4a6a5222e2754eff85e8b2ffa1dd74566b08608e (commit) via 33e04542b1ef367f6e4a170986448b8bd9e90120 (commit) via c553d68798b277506efc361f70987c81fea55fec (commit) from 43eed7fe11168d70f802cadc7c40a726da679774 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4a6a5222e2754eff85e8b2ffa1dd74566b08608e commit 4a6a5222e2754eff85e8b2ffa1dd74566b08608e Merge: 43eed7f 33e0454 Author: Brad King brad.k...@kitware.com AuthorDate: Thu May 1 09:30:32 2014 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Thu May 1 09:30:32 2014 -0400 Merge branch 'master' into next --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.0.0-rc4-761-g4cbce89
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 4cbce89ba976bef878a75050fd7cced901c23b99 (commit) via 4a5cf9645317d486d7fbddf666878ee302689141 (commit) from 33e04542b1ef367f6e4a170986448b8bd9e90120 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4cbce89ba976bef878a75050fd7cced901c23b99 commit 4cbce89ba976bef878a75050fd7cced901c23b99 Merge: 33e0454 4a5cf96 Author: Brad King brad.k...@kitware.com AuthorDate: Thu May 1 09:36:12 2014 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu May 1 09:36:12 2014 -0400 Merge topic 'ExternalData-missing-not-fatal' 4a5cf964 Help: Add notes for topic 'ExternalData-missing-not-fatal' --- Summary of changes: Help/release/dev/ExternalData-missing-not-fatal.rst |8 1 file changed, 8 insertions(+) create mode 100644 Help/release/dev/ExternalData-missing-not-fatal.rst hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.0.0-rc4-763-ga354a8b
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via a354a8ba5e6ad23e2317f684434136bea622154b (commit) via 145d653e5f9390a74bf1bcd095c7f054b34c2fa2 (commit) from 4cbce89ba976bef878a75050fd7cced901c23b99 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a354a8ba5e6ad23e2317f684434136bea622154b commit a354a8ba5e6ad23e2317f684434136bea622154b Merge: 4cbce89 145d653 Author: Brad King brad.k...@kitware.com AuthorDate: Thu May 1 09:36:16 2014 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu May 1 09:36:16 2014 -0400 Merge topic 'UseSWIG-guess_module_name' 145d653e Help: Add notes for topic 'UseSWIG-guess_module_name' --- Summary of changes: Help/release/dev/UseSWIG-guess_module_name.rst |6 ++ 1 file changed, 6 insertions(+) create mode 100644 Help/release/dev/UseSWIG-guess_module_name.rst hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.0.0-rc4-2671-gb675e4f
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via b675e4f48b29b811c7f2a7e0ca603b4a4b428bef (commit) via a354a8ba5e6ad23e2317f684434136bea622154b (commit) via 4cbce89ba976bef878a75050fd7cced901c23b99 (commit) from 4a6a5222e2754eff85e8b2ffa1dd74566b08608e (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b675e4f48b29b811c7f2a7e0ca603b4a4b428bef commit b675e4f48b29b811c7f2a7e0ca603b4a4b428bef Merge: 4a6a522 a354a8b Author: Brad King brad.k...@kitware.com AuthorDate: Thu May 1 09:37:28 2014 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Thu May 1 09:37:28 2014 -0400 Merge branch 'master' into next --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.0.0-rc4-2675-g3402e60
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 3402e60764e6dbb3626305a5a36a2d0ab4d1881d (commit)
via 56d3161648b29d1a6c3c095891fe7fc7f9323200 (commit)
via e8f113d51543ad440e2c3e915f2523ce10b93195 (commit)
via 425e34bac2a69388bf78156ec828522d5fb79fb1 (commit)
from b675e4f48b29b811c7f2a7e0ca603b4a4b428bef (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3402e60764e6dbb3626305a5a36a2d0ab4d1881d
commit 3402e60764e6dbb3626305a5a36a2d0ab4d1881d
Merge: b675e4f 56d3161
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu May 1 10:37:31 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu May 1 10:37:31 2014 -0400
Merge topic 'dev/faster-evis' into next
56d31616 CMP0053: Fix RunCMake.Syntax test for new policy summary
e8f113d5 CMP0053: Revise documentation of this policy
425e34ba Help: Add more reference targets to cmake-language.7
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=56d3161648b29d1a6c3c095891fe7fc7f9323200
commit 56d3161648b29d1a6c3c095891fe7fc7f9323200
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu May 1 10:23:05 2014 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu May 1 10:38:02 2014 -0400
CMP0053: Fix RunCMake.Syntax test for new policy summary
diff --git a/Tests/RunCMake/Syntax/CMP0053-At-WARN-stderr.txt
b/Tests/RunCMake/Syntax/CMP0053-At-WARN-stderr.txt
index 718af8b..48b6a24 100644
--- a/Tests/RunCMake/Syntax/CMP0053-At-WARN-stderr.txt
+++ b/Tests/RunCMake/Syntax/CMP0053-At-WARN-stderr.txt
@@ -1,7 +1,7 @@
^CMake Warning \(dev\) at CMP0053-At-WARN.cmake:4 \(set\):
- Policy CMP0053 is not set: Use the new variable expansion rules. Run
- cmake --help-policy CMP0053 for policy details. Use the cmake_policy
- command to set the policy and suppress this warning.
+ Policy CMP0053 is not set: Simplify variable reference and escape sequence
+ evaluation. Run cmake --help-policy CMP0053 for policy details. Use the
+ cmake_policy command to set the policy and suppress this warning.
Input: '@var@'
Old expansion: '\${right}'
diff --git a/Tests/RunCMake/Syntax/CMP0053-WARN-stderr.txt
b/Tests/RunCMake/Syntax/CMP0053-WARN-stderr.txt
index 8a4bf46..3443603 100644
--- a/Tests/RunCMake/Syntax/CMP0053-WARN-stderr.txt
+++ b/Tests/RunCMake/Syntax/CMP0053-WARN-stderr.txt
@@ -1,7 +1,7 @@
^CMake Warning \(dev\) at CMP0053-WARN.cmake:2 \(message\):
- Policy CMP0053 is not set: Use the new variable expansion rules. Run
- cmake --help-policy CMP0053 for policy details. Use the cmake_policy
- command to set the policy and suppress this warning.
+ Policy CMP0053 is not set: Simplify variable reference and escape sequence
+ evaluation. Run cmake --help-policy CMP0053 for policy details. Use the
+ cmake_policy command to set the policy and suppress this warning.
Input: '\\'
Old behavior is accepted and the new behavior causes an error: 'Syntax
error in cmake code at
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e8f113d51543ad440e2c3e915f2523ce10b93195
commit e8f113d51543ad440e2c3e915f2523ce10b93195
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu May 1 10:21:23 2014 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu May 1 10:38:02 2014 -0400
CMP0053: Revise documentation of this policy
diff --git a/Help/policy/CMP0010.rst b/Help/policy/CMP0010.rst
index 4f0c8e5..9d2eb76 100644
--- a/Help/policy/CMP0010.rst
+++ b/Help/policy/CMP0010.rst
@@ -10,8 +10,8 @@ variable reference is an error. The OLD behavior for this
policy is
to warn about the error, leave the string untouched, and continue.
The NEW behavior for this policy is to report an error.
-If :policy:`CMP0053` is used, this policy has no effect and is treated as
-always being NEW.
+If :policy:`CMP0053` is set to ``NEW``, this policy has no effect
+and is treated as always being ``NEW``.
This policy was introduced in CMake version 2.6.3. CMake version
|release| warns when the policy is not set and uses OLD behavior. Use
diff --git a/Help/policy/CMP0053.rst b/Help/policy/CMP0053.rst
index 820eb9e..ba7ebd3 100644
--- a/Help/policy/CMP0053.rst
+++ b/Help/policy/CMP0053.rst
@@ -1,26 +1,38 @@
CMP0053
---
-Use new variable expansion rules.
+Simplify variable reference and escape sequence evaluation.
-CMake 3.0 and lower used an older, slower implementation of variable expansion
-which offered some behavior no longer allowed by the new parser. Specifically,
-'@' expansion is no longer performed in files not configured using
-:command:`configure_file` or
[Cmake-commits] CMake branch, next, updated. v3.0.0-rc4-2680-gb085788
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via b085788ea4ac01b2bd53ccc65c60287295610b95 (commit)
via 0bcf3e9b5d2a4a156d39ca4092fd496309546239 (commit)
via 0561497410a1b07c256adf146bc2e86a7bf7b954 (commit)
via 040edebb9f1069f403f8c9bce6f81dbaaf589505 (commit)
via 4a74abcec4657ebd3349c1dfad3a8fbf6a9151fe (commit)
from 3402e60764e6dbb3626305a5a36a2d0ab4d1881d (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b085788ea4ac01b2bd53ccc65c60287295610b95
commit b085788ea4ac01b2bd53ccc65c60287295610b95
Merge: 3402e60 0bcf3e9
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Thu May 1 13:49:21 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu May 1 13:49:21 2014 -0400
Merge topic 'dev/faster-evis' into next
0bcf3e9b tests: Add tests for spaces and tabs in variable names
05614974 EVIS: Output the variable-as-parsed in error message
040edebb CMP0053: Fix some weird wording
4a74abce Help: Update valid variable characters in cmake-language.7
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0bcf3e9b5d2a4a156d39ca4092fd496309546239
commit 0bcf3e9b5d2a4a156d39ca4092fd496309546239
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Thu May 1 13:54:24 2014 -0400
Commit: Ben Boeckel ben.boec...@kitware.com
CommitDate: Thu May 1 13:54:51 2014 -0400
tests: Add tests for spaces and tabs in variable names
diff --git a/Tests/RunCMake/Syntax/CMP0053-NameWithEscapedSpaces-result.txt
b/Tests/RunCMake/Syntax/CMP0053-NameWithEscapedSpaces-result.txt
new file mode 100644
index 000..d00491f
--- /dev/null
+++ b/Tests/RunCMake/Syntax/CMP0053-NameWithEscapedSpaces-result.txt
@@ -0,0 +1 @@
+1
diff --git a/Tests/RunCMake/Syntax/CMP0053-NameWithEscapedSpaces-stderr.txt
b/Tests/RunCMake/Syntax/CMP0053-NameWithEscapedSpaces-stderr.txt
new file mode 100644
index 000..df67d37
--- /dev/null
+++ b/Tests/RunCMake/Syntax/CMP0053-NameWithEscapedSpaces-stderr.txt
@@ -0,0 +1,4 @@
+^CMake Error at CMP0053-NameWithEscapedSpaces.cmake:2 \(message\):
+ message called with incorrect number of arguments
+Call Stack \(most recent call first\):
+ CMakeLists.txt:3 \(include\)
diff --git a/Tests/RunCMake/Syntax/CMP0053-NameWithEscapedSpaces.cmake
b/Tests/RunCMake/Syntax/CMP0053-NameWithEscapedSpaces.cmake
new file mode 100644
index 000..805b2ca
--- /dev/null
+++ b/Tests/RunCMake/Syntax/CMP0053-NameWithEscapedSpaces.cmake
@@ -0,0 +1,2 @@
+cmake_policy(SET CMP0053 NEW)
+message(${var\ with\ escaped\ space})
diff --git a/Tests/RunCMake/Syntax/CMP0053-NameWithEscapedSpacesQuoted.cmake
b/Tests/RunCMake/Syntax/CMP0053-NameWithEscapedSpacesQuoted.cmake
new file mode 100644
index 000..58d8e8f
--- /dev/null
+++ b/Tests/RunCMake/Syntax/CMP0053-NameWithEscapedSpacesQuoted.cmake
@@ -0,0 +1,2 @@
+cmake_policy(SET CMP0053 NEW)
+message(${var\ with\ escaped\ space})
diff --git a/Tests/RunCMake/Syntax/CMP0053-NameWithEscapedTabs-result.txt
b/Tests/RunCMake/Syntax/CMP0053-NameWithEscapedTabs-result.txt
new file mode 100644
index 000..d00491f
--- /dev/null
+++ b/Tests/RunCMake/Syntax/CMP0053-NameWithEscapedTabs-result.txt
@@ -0,0 +1 @@
+1
diff --git a/Tests/RunCMake/Syntax/CMP0053-NameWithEscapedTabs-stderr.txt
b/Tests/RunCMake/Syntax/CMP0053-NameWithEscapedTabs-stderr.txt
new file mode 100644
index 000..059044f
--- /dev/null
+++ b/Tests/RunCMake/Syntax/CMP0053-NameWithEscapedTabs-stderr.txt
@@ -0,0 +1,4 @@
+^CMake Error at CMP0053-NameWithEscapedTabs.cmake:2 \(message\):
+ message called with incorrect number of arguments
+Call Stack \(most recent call first\):
+ CMakeLists.txt:3 \(include\)
diff --git a/Tests/RunCMake/Syntax/CMP0053-NameWithEscapedTabs.cmake
b/Tests/RunCMake/Syntax/CMP0053-NameWithEscapedTabs.cmake
new file mode 100644
index 000..214ab5d
--- /dev/null
+++ b/Tests/RunCMake/Syntax/CMP0053-NameWithEscapedTabs.cmake
@@ -0,0 +1,2 @@
+cmake_policy(SET CMP0053 NEW)
+message(${var\ with\ escaped\tab})
diff --git a/Tests/RunCMake/Syntax/CMP0053-NameWithEscapedTabsQuoted.cmake
b/Tests/RunCMake/Syntax/CMP0053-NameWithEscapedTabsQuoted.cmake
new file mode 100644
index 000..aa5123f
--- /dev/null
+++ b/Tests/RunCMake/Syntax/CMP0053-NameWithEscapedTabsQuoted.cmake
@@ -0,0 +1,2 @@
+cmake_policy(SET CMP0053 NEW)
+message(${var\with\ escaped\tab})
diff --git a/Tests/RunCMake/Syntax/CMP0053-NameWithSpaces-result.txt
b/Tests/RunCMake/Syntax/CMP0053-NameWithSpaces-result.txt
new file mode 100644
index 000..d00491f
--- /dev/null
+++ b/Tests/RunCMake/Syntax/CMP0053-NameWithSpaces-result.txt
@@
[Cmake-commits] CMake branch, next, updated. v3.0.0-rc4-2683-g19dc6d0
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 19dc6d010dba3a135f71d61a9bfee562d1016868 (commit)
via d720a7cbb80e849f541f05e03fae8f060af2150c (commit)
via d5174e3b5ca94d14dd020024d347831b093f2a4b (commit)
from b085788ea4ac01b2bd53ccc65c60287295610b95 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=19dc6d010dba3a135f71d61a9bfee562d1016868
commit 19dc6d010dba3a135f71d61a9bfee562d1016868
Merge: b085788 d720a7c
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Thu May 1 14:43:03 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu May 1 14:43:03 2014 -0400
Merge topic 'dev/faster-evis' into next
d720a7cb Help: Add documentation on escaping changes with CMP0053
d5174e3b EVIS: Remove strings from the stack
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d720a7cbb80e849f541f05e03fae8f060af2150c
commit d720a7cbb80e849f541f05e03fae8f060af2150c
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Thu May 1 14:47:18 2014 -0400
Commit: Ben Boeckel ben.boec...@kitware.com
CommitDate: Thu May 1 14:47:18 2014 -0400
Help: Add documentation on escaping changes with CMP0053
diff --git a/Help/manual/cmake-language.7.rst b/Help/manual/cmake-language.7.rst
index e8d2670..45f4bac 100644
--- a/Help/manual/cmake-language.7.rst
+++ b/Help/manual/cmake-language.7.rst
@@ -296,16 +296,15 @@ An *escape sequence* is a ``\`` followed by one character:
.. productionlist::
escape_sequence: `escape_identity` | `escape_encoded` | `escape_semicolon`
- escape_identity: '\(' | '\)' | '\#' | '\' | '\ ' |
-: '\\' | '\$' | '\@' | '\^'
+ escape_identity: '\' match '[^a-zA-Z]'
escape_encoded: '\t' | '\r' | '\n'
escape_semicolon: '\;'
-A ``\`` followed by one of ``()# \#@^`` simply encodes the literal
+A ``\`` followed by a non-alphanumeric character simply encodes the literal
character without interpreting it as syntax. A ``\t``, ``\r``, or ``\n``
-encodes a tab, carriage return, or newline character, respectively.
-A ``\;`` encodes itself but may be used in an `Unquoted Argument`_
-to encode the ``;`` without dividing the argument value on it.
+encodes a tab, carriage return, or newline character, respectively. A ``\;``
+encodes itself but may be used in an `Unquoted Argument`_ to encode the ``;``
+without dividing the argument value on it.
.. _`Variable References`:
diff --git a/Help/policy/CMP0053.rst b/Help/policy/CMP0053.rst
index 542de63..9657368 100644
--- a/Help/policy/CMP0053.rst
+++ b/Help/policy/CMP0053.rst
@@ -28,6 +28,12 @@ cleaned up to simplify the behavior. Specifically:
* The setting of policy :policy:`CMP0010` is not considered,
so improper variable reference syntax is always an error.
+* More characters are allowed to be escaped in variable names.
+ Previously, only ``()# \#@^`` were valid characters to
+ escape. Now any non-alphanumeric, non-semicolon, non-NUL
+ character may be escaped following the ``escape_identity``
+ rule from :manual:`cmake-language`.
+
The ``OLD`` behavior for this policy is to honor the legacy behavior for
variable references and escape sequences. The ``NEW`` behavior is to
use the simpler variable expansion and escape sequence evaluation rules.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d5174e3b5ca94d14dd020024d347831b093f2a4b
commit d5174e3b5ca94d14dd020024d347831b093f2a4b
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Thu May 1 14:34:06 2014 -0400
Commit: Ben Boeckel ben.boec...@kitware.com
CommitDate: Thu May 1 14:34:06 2014 -0400
EVIS: Remove strings from the stack
Keep a single string around and build it up incrementally. This avoids
string allocation within the stack which is much faster.
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index cc52c24..481bb05 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -2813,7 +2813,7 @@ typedef enum
struct t_lookup
{
t_domain domain;
- std::string lookup;
+ size_t loc;
};
cmake::MessageType cmMakefile::ExpandVariablesInStringNew(
@@ -2834,6 +2834,8 @@ cmake::MessageType cmMakefile::ExpandVariablesInStringNew(
const char* in = source.c_str();
const char* last = in;
+ std::string result;
+ result.reserve(source.size());
std::stackt_lookup openstack;
bool error = false;
bool done = false;
@@ -2850,8 +2852,8 @@ cmake::MessageType cmMakefile::ExpandVariablesInStringNew(
{
t_lookup var = openstack.top();
openstack.pop();
- std::string lookup = var.lookup;
-
[Cmake-commits] CMake branch, next, updated. v3.0.0-rc4-2685-g2afb232
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 2afb232456586a2803034dea8c77226fa2a4eeaf (commit)
via 3bd7628953faa0a08790001dc75e8d1b52f10631 (commit)
from 19dc6d010dba3a135f71d61a9bfee562d1016868 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2afb232456586a2803034dea8c77226fa2a4eeaf
commit 2afb232456586a2803034dea8c77226fa2a4eeaf
Merge: 19dc6d0 3bd7628
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Thu May 1 15:03:29 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu May 1 15:03:29 2014 -0400
Merge topic 'dev/faster-evis' into next
3bd76289 EVIS: Fix CMAKE_CURRENT_LIST_LINE
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3bd7628953faa0a08790001dc75e8d1b52f10631
commit 3bd7628953faa0a08790001dc75e8d1b52f10631
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Thu May 1 15:09:20 2014 -0400
Commit: Ben Boeckel ben.boec...@kitware.com
CommitDate: Thu May 1 15:09:20 2014 -0400
EVIS: Fix CMAKE_CURRENT_LIST_LINE
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 481bb05..3339c16 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -2855,6 +2855,7 @@ cmake::MessageType cmMakefile::ExpandVariablesInStringNew(
result.append(last, in - last);
std::string const lookup = result.substr(var.loc);
const char* value = NULL;
+ std::string varresult;
static const std::string lineVar = CMAKE_CURRENT_LIST_LINE;
switch(var.domain)
{
@@ -2863,7 +2864,7 @@ cmake::MessageType cmMakefile::ExpandVariablesInStringNew(
{
cmOStringStream ostr;
ostr line;
-result.append(ostr.str());
+varresult = ostr.str();
}
else
{
@@ -2878,7 +2879,6 @@ cmake::MessageType cmMakefile::ExpandVariablesInStringNew(
break;
}
// Get the string we're meant to append to.
- std::string varresult;
if(value)
{
if(escapeQuotes)
---
Summary of changes:
Source/cmMakefile.cxx |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.0.0-rc4-2689-g95137ad
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 95137add8e3ff19a4e69bfb077f937796a4466e2 (commit)
via 3f51752264bc1243fa2e56da41131ac363d3bd85 (commit)
via ef62fbad55deedd4b985f0900f1ee983eaa0072d (commit)
via f718b30a95e07d72a361d55b7ba495eda5d79680 (commit)
from 2afb232456586a2803034dea8c77226fa2a4eeaf (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=95137add8e3ff19a4e69bfb077f937796a4466e2
commit 95137add8e3ff19a4e69bfb077f937796a4466e2
Merge: 2afb232 3f51752
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Thu May 1 17:11:55 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu May 1 17:11:55 2014 -0400
Merge topic 'dev/regex-variables' into next
3f517522 StoreMatches: Minor cleanups
ef62fbad ClearMatches: Store match variable names statically
f718b30a ClearMatches: Only clear matches which were actually set
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3f51752264bc1243fa2e56da41131ac363d3bd85
commit 3f51752264bc1243fa2e56da41131ac363d3bd85
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Wed Mar 12 14:26:45 2014 -0400
Commit: Ben Boeckel ben.boec...@kitware.com
CommitDate: Tue Apr 29 16:00:06 2014 -0400
StoreMatches: Minor cleanups
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index b71e113..de329f0 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -4366,11 +4366,11 @@ void cmMakefile::StoreMatches(cmsys::RegularExpression
re)
{
for (unsigned int i=0; i10; i++)
{
-std::string m = re.match(i);
-if(m.size() 0)
+std::string const m = re.match(i);
+if(!m.empty())
{
std::string const var = matchVariables[i];
- this-AddDefinition(var, re.match(i).c_str());
+ this-AddDefinition(var, m.c_str());
this-MarkVariableAsUsed(var);
this-NumLastMatches = i + 1;
}
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ef62fbad55deedd4b985f0900f1ee983eaa0072d
commit ef62fbad55deedd4b985f0900f1ee983eaa0072d
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Wed Mar 12 14:25:59 2014 -0400
Commit: Ben Boeckel ben.boec...@kitware.com
CommitDate: Tue Apr 29 16:00:05 2014 -0400
ClearMatches: Store match variable names statically
Constructing the names and then turning them into a std::string is
non-negligible in performance testing.
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 262f29d..b71e113 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -4332,20 +4332,30 @@ std::vectorcmSourceFile*
cmMakefile::GetQtUiFilesWithOptions() const
return this-QtUiFilesWithOptions;
}
+static std::string matchVariables[] = {
+ CMAKE_MATCH_0,
+ CMAKE_MATCH_1,
+ CMAKE_MATCH_2,
+ CMAKE_MATCH_3,
+ CMAKE_MATCH_4,
+ CMAKE_MATCH_5,
+ CMAKE_MATCH_6,
+ CMAKE_MATCH_7,
+ CMAKE_MATCH_8,
+ CMAKE_MATCH_9
+};
+
//
void cmMakefile::ClearMatches()
{
- std::stringstream sstr;
for (unsigned int i=0; ithis-NumLastMatches; i++)
{
-sstr.str();
-sstr CMAKE_MATCH_ i;
-std::string const name = sstr.str();
-std::string const s = this-GetSafeDefinition(name);
+std::string const var = matchVariables[i];
+std::string const s = this-GetSafeDefinition(var);
if(!s.empty())
{
- this-AddDefinition(name, );
- this-MarkVariableAsUsed(name);
+ this-AddDefinition(var, );
+ this-MarkVariableAsUsed(var);
}
}
this-NumLastMatches = 0;
@@ -4359,10 +4369,9 @@ void cmMakefile::StoreMatches(cmsys::RegularExpression
re)
std::string m = re.match(i);
if(m.size() 0)
{
- char name[128];
- sprintf(name, CMAKE_MATCH_%d, i);
- this-AddDefinition(name, re.match(i).c_str());
- this-MarkVariableAsUsed(name);
+ std::string const var = matchVariables[i];
+ this-AddDefinition(var, re.match(i).c_str());
+ this-MarkVariableAsUsed(var);
this-NumLastMatches = i + 1;
}
}
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f718b30a95e07d72a361d55b7ba495eda5d79680
commit f718b30a95e07d72a361d55b7ba495eda5d79680
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Wed Mar 12 14:23:12 2014 -0400
Commit: Ben Boeckel ben.boec...@kitware.com
CommitDate: Tue Apr 29 16:00:05 2014 -0400
ClearMatches: Only clear matches which were actually set
ClearMatches was clearing many variables which were never set in the
first place. Instead, store how many matches were made last
[Cmake-commits] CMake branch, master, updated. v3.0.0-rc4-764-g2615185
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 261518541891914cb79545a0f96679d4a97f27f8 (commit) from a354a8ba5e6ad23e2317f684434136bea622154b (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=261518541891914cb79545a0f96679d4a97f27f8 commit 261518541891914cb79545a0f96679d4a97f27f8 Author: Kitware Robot kwro...@kitware.com AuthorDate: Fri May 2 00:01:07 2014 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Fri May 2 00:01:07 2014 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 44241b6..af2d062 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 0) -set(CMake_VERSION_PATCH 20140501) +set(CMake_VERSION_PATCH 20140502) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
