[CMake] Missing libgmp-10.dll
Hello, I recently started using CMake, and I'm trying to build a Code::Blocks MinGW project. I downloaded CMake 2.8.4 for Windows 32-bit; my Windows version is 64-bit, but it seems that shouldn't cause problems. Using the CMake GUI, I'm trying to build a project, but I keep getting the same error message: apparently, CMake is missing libgmp-10.dll. I believe the file CMake is looking for is in the MinGW/bin folder. I think I'm supposed to somehow link it in the GUI window, but I'm not sure how. Do I have to add a cache entry? If so, what do I need to specify? Thank you. Latin1 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Missing libgmp-10.dll
Hi, when you install MinGW, the minGW/bin directory is not added to the PATH variable. So you need to add your minGW/bin directory to your path variable, so CMake can find the needed libraries. Maxime Le 02/06/2011 21:52, Julien Lemay a écrit : Hello, I recently started using CMake, and I'm trying to build a Code::Blocks MinGW project. I downloaded CMake 2.8.4 for Windows 32-bit; my Windows version is 64-bit, but it seems that shouldn't cause problems. Using the CMake GUI, I'm trying to build a project, but I keep getting the same error message: apparently, CMake is missing libgmp-10.dll. I believe the file CMake is looking for is in the MinGW/bin folder. I think I'm supposed to somehow link it in the GUI window, but I'm not sure how. Do I have to add a cache entry? If so, what do I need to specify? Thank you. Latin1 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] False.lib error while linking
On 6/1/2011 6:11 AM, AMARNATH, Balachandar wrote:
Dear Bill,
When i did cmake --trace, I could see at some places BLAS_LIBRARIES are
set to FALSE. Particularly, here in below lines
***
...
c:/Users/BAAMARNA5617/Programs/CMake
2.8/share/cmake-2.8/Modules/FindBLAS.cmake(114): if(NOT _libraries_work )
*c:/Users/BAAMARNA5617/Programs/CMake
2.8/share/cmake-2.8/Modules/FindBLAS.cmake(115): set(BLAS_LIBRARIES FALSE )*
c:/Users/BAAMARNA5617/Programs/CMake
2.8/share/cmake-2.8/Modules/FindBLAS.cmake(401): if(NOT BLAS_LIBRARIES )
c:/Users/BAAMARNA5617/Programs/CMake
2.8/share/cmake-2.8/Modules/FindBLAS.cmake(402):
check_fortran_libraries(BLAS_LIBRARIES BLAS sgemm mkl;guide
${CMAKE_THREAD_LIBS_INIT};${LM} )
**
This, I believe, due to missing of libguide40 library which is required
by FindBLAS.cmake module. Because of this, LAPACK_LIBRARIES are also set
to FALSE. They are linked to 'mpf' library through
target_link_libraries(${LAPACK_LIBRARIES} ${BLAS_LIBRARIES} ...). By the
way, i use Intel MKL for blas and lapack libraries.
Regards
Balachandar
So, your code should check the results of FindBLAS before using the
variables. You could create a copy of FindBLAS.cmake specific to your
project. If you have patches for the file I would look at them as well.
You could also email the module maintainer for FindBLAS.cmake for help:
http://www.itk.org/Wiki/CMake:Module_Maintainers
-Bill
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] VS2010 and OUTPUT_NAME problem
On 05/28/2011 12:33 PM, Thomas Roß wrote:
set( CMAKE_RUNTIME_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/bin CACHE PATH )
to have all my executables in one place
This doesn't need to be in the cache. You can just set() it in the top level.
used set_target_properties( plugin PROPERTIES OUTPUT_NAME plugins/plugin )
on the plugin target to get it created in the needed subdirectory.
The OUTPUT_NAME property does not support slashes. It worked only by accident
in other generators.
The proper way to do this is to set the RUNTIME_OUTPUT_DIRECTORY on the target.
The documentation of the CMAKE_RUNTIME_OUTPUT_DIRECTORY:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#variable:CMAKE_RUNTIME_OUTPUT_DIRECTORY
says just
used to initialize the RUNTIME_OUTPUT_DIRECTORY property on all the targets
By setting the variable at the top you set the default used for all targets.
You can still change it for a specific target:
set_property(TARGET plugin PROPERTY
RUNTIME_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/bin/plugins)
-Brad
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Missing libgmp-10.dll
On 6/2/2011 4:01 PM, Lecourt Maxime wrote: Hi, when you install MinGW, the minGW/bin directory is not added to the PATH variable. So you need to add your minGW/bin directory to your path variable, so CMake can find the needed libraries. Seems that MinGW changed something recently... This is the second issue I have seen. It used to be they had all the dll and exe files in one directory, so that Windows could always find them. What version of MinGW is causing the trouble? I have 5.16 and it does not have to be in the PATH. It works for me: The C compiler identification is GNU The CXX compiler identification is GNU Check for working C compiler: C:/MinGW/bin/gcc.exe Check for working C compiler: C:/MinGW/bin/gcc.exe -- works Detecting C compiler ABI info Detecting C compiler ABI info - done Check for working CXX compiler: C:/MinGW/bin/g++.exe Check for working CXX compiler: C:/MinGW/bin/g++.exe -- works Detecting CXX compiler ABI info Detecting CXX compiler ABI info - done Configuring done -Bill ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Windows build inconsistency...
I've noticed an inconsistency in CMake's generation.. For example I go through the following sequence: cd \Project mkdir Debug cd Debug Then I either: cmake -G Visual Studio 9 2008 -DCMAKE_BUILD_TYPE=Debug ..\CMakeLists.txt It will generate, and then place the project files in \Project. But if I use: cmake -G Visual Studio 9 2008 -DCMAKE_BUILD_TYPE=Debug .. It will generate, and then place the project files in \Project\Debug Why are these different? Are the differences expected behavior? I'm a bit confused.. Thanks! ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Windows build inconsistency...
Just tested it on linux and the same remark applies. //- Case1: mkdir TestCase1 mkdir TestCase1/Debug echo PROJECT(foo) TestCase1/CMakeLists.txt cd TestCase1/Debug cmake ../CMakeLists.txt Output: -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/local/bin/gcc -- Check for working C compiler: /usr/local/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/local/bin/c++ -- Check for working CXX compiler: /usr/local/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Configuring done -- Generating done -- Build files have been written to: /home/jchris/Projects/TestInSource/TestCase1 //- Case2: mkdir TestCase2 mkdir TestCase2/Debug echo PROJECT(foo) TestCase2/CMakeLists.txt cd TestCase2/Debug cmake .. Output -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/local/bin/gcc -- Check for working C compiler: /usr/local/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/local/bin/c++ -- Check for working CXX compiler: /usr/local/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Configuring done -- Generating done -- Build files have been written to: /home/jchris/Projects/TestInSource/TestCase2/Debug Jc On Thu, Jun 2, 2011 at 6:29 PM, The Novice Coder cm...@randmsystems.comwrote: I've noticed an inconsistency in CMake's generation.. For example I go through the following sequence: cd \Project mkdir Debug cd Debug Then I either: cmake -G Visual Studio 9 2008 -DCMAKE_BUILD_TYPE=Debug ..\CMakeLists.txt It will generate, and then place the project files in \Project. But if I use: cmake -G Visual Studio 9 2008 -DCMAKE_BUILD_TYPE=Debug .. It will generate, and then place the project files in \Project\Debug Why are these different? Are the differences expected behavior? I'm a bit confused.. Thanks! ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- +1 919 869 8849 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Status of FindHDF5.cmake in CMake?
We've run into another issue with the way FindHDF5 works. On Cray systems, h5fc -show gives: ifort -fPIC -I/opt/cray/hdf5/1.8.5.0/hdf5-intel/include -L/opt/cray/hdf5/1.8.5.0/hdf5-intel/lib /opt/cray/hdf5/1.8.5.0/hdf5-intel/lib/libhdf5hl_fortran.a /opt/cray/hdf5/1.8.5.0/hdf5-intel/lib/libhdf5_hl.a /opt/cray/hdf5/1.8.5.0/hdf5-intel/lib/libhdf5_fortran.a /opt/cray/hdf5/1.8.5.0/hdf5-intel/lib/libhdf5.a -lz -lm -Wl,-rpath -Wl,/opt/cray/hdf5/1.8.5.0/hdf5-intel/lib -L/usr/lib64 The FindHDF5 complains it can't find the libraries because it looks for the -l* portions and doesn't find the lines giving the .a files. I will try to think of a general way to make this work, but I'm not very well versed in cmake. So if anybody has any suggestions or knows how to fix it, we'd sure appreciate it! Tim - Original Message - From: Tim Gallagher tim.gallag...@gatech.edu To: cmake@cmake.org Sent: Friday, May 20, 2011 6:07:50 PM Subject: Re: [CMake] Status of FindHDF5.cmake in CMake? Will, Sorry for the delay in responding. We tested the FindHDF5 you attached and it correctly located the Fortran libraries. Thanks for including it in the updated version! Tim - Original Message - From: Will Dicharry wdicha...@stellarscience.com To: J.S. van Bethlehem j.s.van.bethle...@astro.rug.nl Cc: cmake@cmake.org Sent: Friday, May 20, 2011 5:32:16 PM Subject: Re: [CMake] Status of FindHDF5.cmake in CMake? J.S. van Bethlehem wrote: Hej Will, I'm not sure if this is the proper way to reply and I haven't checked your second mail with the attachment. But I think in #3 you're definitely doing something wrong. It took me quite a while to figure out, because the documentation is rather sparse, but whenever there is a hdf5-config.cmake file, you should not read that from a Find*.cmake file. Whenever there is such a file present, what should happen is that CMake finds it and reads it and that's that. Even more precise: whenever a user writes find_package(HDF5) and the hdf5-config.cmake exists, CMake will read that file and will NOT go look for FindHDF5.cmake. The hdf5-config.cmake should then explicitly set all the (cached) variables you normally would have to 'calculate' in the FindHDF5.cmake file. So to be short: the FindHDF5.cmake file should never be required to look for hdf5-config.cmake - CMake should be left to be the one to do that. The HDF5 installer should be the one that installs the hdf5-config.cmake into for example prefix/share/HDF5/cmake or some similar path (look for documentation of find_package for possible locations where CMake will look) From previous instructions by the Kitware developers, I was under the impression that I needed to do something like find_package( HDF5 QUIET NO_MODULE ) from the FindHDF5.cmake module. It looks like FindVTK does this. Either way, the HDF5 CMake build does not set the standard *_INCLUDE_DIRS and *_LIBRARIES variables in the config file, so I have to do something. Can a Kitware person shed some light on this? Thanks, Will But again: I haven't read the actual file you created :P Maybe I'm overlooking some details of this particular package. Greetsz, Jakob Will Dicharry wrote: Hi All, I neglected the FindHDF5 module for a while because I was shifted to another project that was kind of far from CMake work, but there were a few requests for fixes features to the module. I think I have a file that has the important ones. It's attached to this message. Brad, I know I had CVS access, but I don't think I have Git access. If you'd like me to push my commits, I can but I think I'd need you to reauthorize me to do so. The changes to this module are: 1. Tim Gallagher's (cc'd) patch to handle the HDF5 Fortran library. 2. hdf5_hl is now an optional component that can be requested like the language bindings. 3. If I can find hdf5-config.cmake from the native HDF5 cmake build, I use it. I'd like it if the people I cc'd (who appear to be interested in at least one of these features) could try it and see if it works for them. I'd also like to know if I did #3 correctly, since there don't really appear to be any modules in the CMake repository that wrap around config files that don't set the variables defined in the Find module. Thanks, Will ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the
[CMake] Scanning dependencies of target xxx is very slow.
Hey all; I am a new bible of CMAKE, I just use cmake to rewrite my previous project, the problem is that the process Scanning dependencies of target is really very slow, it will always take more than 20 to 30 minutes for scanning. What does CMAKE do to scan dependencies of target? Why so slow? Is it my project source files dependency issue? If yes, how do I improve it? Could you give me some guidence? Thanks in advance. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Scanning dependencies of target xxx is very slow.
On Friday, June 03, 2011 04:01:54 AM jianhua wrote: Hey all; I am a new bible of CMAKE, I just use cmake to rewrite my previous project, the problem is that the process Scanning dependencies of target is really very slow, it will always take more than 20 to 30 minutes for scanning. What does CMAKE do to scan dependencies of target? Why so slow? Is it my project source files dependency issue? If yes, how do I improve it? Could you give me some guidence? Usually it is not that slow. Can you give us some more information ? Of how many files consists your target approximately ? Under which operating system ? Is it maybe on NFS or samba ? Alex ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.4-1654-gd1a62ce
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 d1a62ce7a6034ef54bc4c30128af2cb6e2ca31e2 (commit) via 5764739f52095d6be5bb8d105335c58974ee40ec (commit) from 955f96d3e855ea11df5bf73b1211d9c060d00917 (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=d1a62ce7a6034ef54bc4c30128af2cb6e2ca31e2 commit d1a62ce7a6034ef54bc4c30128af2cb6e2ca31e2 Merge: 955f96d 5764739 Author: Brad King brad.k...@kitware.com AuthorDate: Thu Jun 2 09:54:44 2011 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Thu Jun 2 09:54:44 2011 -0400 Merge branch 'master' into next --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 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. v2.8.4-1659-g4f8dde2
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 4f8dde2da662cc3021cb202a274fe2018830c446 (commit)
via 41f962a2cb239616e75f5de12d8987609dc4cde6 (commit)
via e17135e882188145e04c2ff455fad01273fdb375 (commit)
from 9a0e659a03ea7b10a7937df676a70d5423e2a710 (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=4f8dde2da662cc3021cb202a274fe2018830c446
commit 4f8dde2da662cc3021cb202a274fe2018830c446
Merge: 9a0e659 41f962a
Author: Clinton Stimpson clin...@elemtech.com
AuthorDate: Thu Jun 2 11:10:44 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Jun 2 11:10:44 2011 -0400
Merge topic 'fix-12034-fixup-bundle-with-non-dotapp-exe' into next
41f962a Revert BundleUtilities: Run test on Windows if either MSVC or
dumpbin was found.
e17135e BundleUtilities: Add rpath to loadable modules in test.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=41f962a2cb239616e75f5de12d8987609dc4cde6
commit 41f962a2cb239616e75f5de12d8987609dc4cde6
Author: Clinton Stimpson clin...@elemtech.com
AuthorDate: Thu Jun 2 09:09:14 2011 -0600
Commit: Clinton Stimpson clin...@elemtech.com
CommitDate: Thu Jun 2 09:09:14 2011 -0600
Revert BundleUtilities: Run test on Windows if either MSVC or dumpbin was
found.
This reverts commit f3de459cec78eac3a7081379b6ee9c6cde36bb60.
There are some platforms without MSVC where this test doesn't work well.
We can look
into these later.
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index be0b3f9..d840b96 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -195,9 +195,7 @@ IF(BUILD_TESTING)
# run test for BundleUtilities on supported platforms/compilers
- find_program(DUMPBIN_EXECUTABLE NAMES dumpbin)
- mark_as_advanced(DUMPBIN_EXECUTABLE)
- if(MSVC OR DUMPBIN_EXECUTABLE OR
+ if(MSVC OR
CMAKE_SYSTEM_NAME MATCHES Linux OR
CMAKE_SYSTEM_NAME MATCHES Darwin)
ADD_TEST(BundleUtilities ${CMAKE_CTEST_COMMAND}
@@ -209,7 +207,7 @@ IF(BUILD_TESTING)
--build-project BundleUtilities
)
LIST(APPEND TEST_BUILD_DIRS ${CMake_BINARY_DIR}/Tests/BundleUtilities)
- endif(MSVC OR DUMPBIN_EXECUTABLE OR
+ endif(MSVC OR
CMAKE_SYSTEM_NAME MATCHES Linux OR
CMAKE_SYSTEM_NAME MATCHES Darwin)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e17135e882188145e04c2ff455fad01273fdb375
commit e17135e882188145e04c2ff455fad01273fdb375
Author: Clinton Stimpson clin...@elemtech.com
AuthorDate: Thu Jun 2 09:08:49 2011 -0600
Commit: Clinton Stimpson clin...@elemtech.com
CommitDate: Thu Jun 2 09:08:49 2011 -0600
BundleUtilities: Add rpath to loadable modules in test.
diff --git a/Tests/BundleUtilities/CMakeLists.txt
b/Tests/BundleUtilities/CMakeLists.txt
index be2b058..6209c8f 100644
--- a/Tests/BundleUtilities/CMakeLists.txt
+++ b/Tests/BundleUtilities/CMakeLists.txt
@@ -9,12 +9,6 @@ add_library(shared SHARED shared.cpp shared.h)
# another shared library
add_library(shared2 SHARED shared2.cpp shared2.h)
-# a loadable module (depends on shared2)
-# test app will load this at runtime
-add_library(module MODULE module.cpp module.h)
-set_target_properties(module PROPERTIES PREFIX )
-get_target_property(module_loc module LOCATION)
-target_link_libraries(module shared2)
# a framework library
add_library(framework SHARED framework.cpp framework.h)
@@ -22,28 +16,37 @@ add_library(framework SHARED framework.cpp framework.h)
#set_target_properties(framework PROPERTIES FRAMEWORK 1)
# make sure rpaths are not helping BundleUtilities or the executables
-set_target_properties(shared shared2 module framework PROPERTIES
+set_target_properties(shared shared2 framework PROPERTIES
SKIP_BUILD_RPATH 1)
## test a Bundle application using dependencies
-set(TESTBUNDLEDIR ${CMAKE_CURRENT_BINARY_DIR}/testdir1)
-add_executable(testbundleutils1 MACOSX_BUNDLE testbundleutils.cpp)
+# a loadable module (depends on shared2)
+# testbundleutils1 will load this at runtime
+add_library(module1 MODULE module.cpp module.h)
+set_target_properties(module1 PROPERTIES PREFIX )
+get_target_property(module_loc module1 LOCATION)
+target_link_libraries(module1 shared2)
+
+# a bundle application
+add_executable(testbundleutils1 MACOSX_BUNDLE testbundleutils1.cpp)
target_link_libraries(testbundleutils1 shared framework ${CMAKE_DL_LIBS})
-set_target_properties(testbundleutils1 PROPERTIES
- INSTALL_RPATH ${TESTBUNDLEDIR}
- BUILD_WITH_INSTALL_RPATH 1)
get_target_property(loc testbundleutils1 LOCATION)
[Cmake-commits] CMake branch, master, updated. v2.8.4-505-g170b4e5
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 170b4e5eae5d93ab130b680f23f323d45fee12ec (commit) via a27edd8a05f61bc01ca749572dfd4110536de5a5 (commit) from e606b6b7db1850cfb6b5dbd1aa553dae5435f73f (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=170b4e5eae5d93ab130b680f23f323d45fee12ec commit 170b4e5eae5d93ab130b680f23f323d45fee12ec Merge: e606b6b a27edd8 Author: Brad King brad.k...@kitware.com AuthorDate: Thu Jun 2 11:29:18 2011 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu Jun 2 11:29:18 2011 -0400 Merge topic 'fix-Xcode-spelling-issue-12231' a27edd8 Fix XCode - Xcode typos, notably in man page (#12231) --- Summary of changes: Source/CMakeLists.txt |2 +- Source/cmGlobalXCodeGenerator.cxx |8 Tests/CFBundleTest/README.txt |2 +- Tests/SimpleInstall/CMakeLists.txt|2 +- Tests/SimpleInstallS2/CMakeLists.txt |2 +- Tests/SourceGroups/CMakeLists.txt |2 +- Tests/TestsWorkingDirectory/CMakeLists.txt|4 ++-- Tests/TestsWorkingDirectory/subdir/CMakeLists.txt |4 ++-- 8 files changed, 13 insertions(+), 13 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, master, updated. v2.8.4-507-g87b8b3c
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 87b8b3c0a0f780daffa4e311e583b02eb8d61e15 (commit) via 3bb85668686738dd1f036bfa3f9eb482cd1581fb (commit) from 170b4e5eae5d93ab130b680f23f323d45fee12ec (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=87b8b3c0a0f780daffa4e311e583b02eb8d61e15 commit 87b8b3c0a0f780daffa4e311e583b02eb8d61e15 Merge: 170b4e5 3bb8566 Author: Brad King brad.k...@kitware.com AuthorDate: Thu Jun 2 11:29:22 2011 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu Jun 2 11:29:22 2011 -0400 Merge topic 'XL-Fortran-moddir-issue-12246' 3bb8566 XL: Place Fortran modules with -qmoddir= flag (#12246) --- Summary of changes: Modules/Compiler/XL-Fortran.cmake |2 ++ 1 files changed, 2 insertions(+), 0 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. v2.8.4-1672-gcea523c
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 cea523cc6982ec3fb7d9f18e17dfc4b826ecfea2 (commit)
via b43af94af1c3f80237fd9889bd5a48e02e279f17 (commit)
from 593bed555dba903900195b73994b4f729ce2f6ad (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=cea523cc6982ec3fb7d9f18e17dfc4b826ecfea2
commit cea523cc6982ec3fb7d9f18e17dfc4b826ecfea2
Merge: 593bed5 b43af94
Author: David Cole david.c...@kitware.com
AuthorDate: Thu Jun 2 14:43:58 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Jun 2 14:43:58 2011 -0400
Merge topic 'eliminate-cvs-from-release-scripts' into next
b43af94 CMake: eliminate use of cvs in the Release scripts
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b43af94af1c3f80237fd9889bd5a48e02e279f17
commit b43af94af1c3f80237fd9889bd5a48e02e279f17
Author: David Cole david.c...@kitware.com
AuthorDate: Wed Jun 1 22:32:42 2011 -0400
Commit: David Cole david.c...@kitware.com
CommitDate: Thu Jun 2 14:36:14 2011 -0400
CMake: eliminate use of cvs in the Release scripts
Set GIT_COMMAND to git -- each machine involved in building
the CMake release binaries has the right git in the PATH.
Separate the release scripts into two batches so we can build
multiple releases on the same machine, in serial, if necessary.
We currnetly do this with the Windows and Cygwin release
binaries on dash2win64.
Sort the files to be uploaded, so that sorting them by modification
time (file copy / upload time) is equivalent to sorting them
alphabetically.
diff --git a/Utilities/Release/create-cmake-release.cmake
b/Utilities/Release/create-cmake-release.cmake
index fd91665..75b0061 100644
--- a/Utilities/Release/create-cmake-release.cmake
+++ b/Utilities/Release/create-cmake-release.cmake
@@ -1,28 +1,42 @@
if(NOT DEFINED CMAKE_CREATE_VERSION)
- message(FATAL_ERROR CMAKE_CREATE_VERSION not defined)
-endif(NOT DEFINED CMAKE_CREATE_VERSION)
+ set(CMAKE_CREATE_VERSION release)
+ message(Using default value of 'release' for CMAKE_CREATE_VERSION)
+endif()
-set(RELEASE_SCRIPTS
+file(MAKE_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/logs)
+
+set(RELEASE_SCRIPTS_BATCH_1
+ dash2win64_release.cmake# Windows
dashmacmini2_release.cmake # Mac Darwin universal
- dashsun1_release.cmake # SunOS
-# destiny_release.cmake # HPUX -- destiny is dead; long live destiny
magrathea_release.cmake # Linux
- dash2win64_release.cmake# Windows
-# dash2win64_cygwin.cmake # Cygwin
-# blight_cygwin.cmake # Cygwin
- v20n250_aix_release.cmake# AIX 5.3
+ dashsun1_release.cmake # SunOS
+ v20n250_aix_release.cmake # AIX 5.3
ferrari_sgi64_release.cmake # IRIX 64
- ferrari_sgi_release.cmake # IRIX 64
+ ferrari_sgi_release.cmake # IRIX
)
-file(WRITE create-${CMAKE_CREATE_VERSION}.sh #!/bin/bash)
-make_directory(${CMAKE_CURRENT_SOURCE_DIR}/logs)
+set(RELEASE_SCRIPTS_BATCH_2
+ dash2win64_cygwin.cmake # Cygwin
+)
-foreach(f ${RELEASE_SCRIPTS})
- file(APPEND create-${CMAKE_CREATE_VERSION}.sh
+function(write_batch_shell_script filename)
+ set(scripts ${ARGN})
+ set(i 0)
+ file(WRITE ${filename} #!/bin/bash)
+ foreach(f ${scripts})
+math(EXPR x 420*(${i}/4))
+math(EXPR y 160*(${i}%4))
+file(APPEND ${filename}
${CMAKE_COMMAND} -DCMAKE_CREATE_VERSION=${CMAKE_CREATE_VERSION} -P
${CMAKE_ROOT}/Utilities/Release/${f} /dev/null
${CMAKE_CURRENT_SOURCE_DIR}/logs/${f}-${CMAKE_CREATE_VERSION}.log
- xterm -geometry 80x10 -sb -sl 2000 -T ${f}-${CMAKE_CREATE_VERSION}.log -e
tail -f ${CMAKE_CURRENT_SOURCE_DIR}/logs/${f}-${CMAKE_CREATE_VERSION}.log)
-endforeach(f)
-execute_process(COMMAND chmod a+x create-${CMAKE_CREATE_VERSION}.sh)
-message(Run ./create-${CMAKE_CREATE_VERSION}.sh)
+xterm -geometry 64x6+${x}+${y} -sb -sl 2000 -T
${f}-${CMAKE_CREATE_VERSION}.log -e tail -f
${CMAKE_CURRENT_SOURCE_DIR}/logs/${f}-${CMAKE_CREATE_VERSION}.log
+)
+math(EXPR i ${i}+1)
+ endforeach(f)
+ execute_process(COMMAND chmod a+x ${filename})
+endfunction()
+
+write_batch_shell_script(create-${CMAKE_CREATE_VERSION}-batch1.sh
${RELEASE_SCRIPTS_BATCH_1})
+write_batch_shell_script(create-${CMAKE_CREATE_VERSION}-batch2.sh
${RELEASE_SCRIPTS_BATCH_2})
+
+message(Run ./create-${CMAKE_CREATE_VERSION}-batch1.sh, then after all those
builds complete, run ./create-${CMAKE_CREATE_VERSION}-batch2.sh)
diff --git a/Utilities/Release/dash2win64_cygwin.cmake
b/Utilities/Release/dash2win64_cygwin.cmake
index 64099a9..da66002 100644
--- a/Utilities/Release/dash2win64_cygwin.cmake
+++
