Re: [cmake-developers] [PATCH] LoadCommand test: cleanup
On Mon, Oct 17, 2011 at 9:18 AM, Rolf Eike Beer e...@sf-mail.de wrote:
On 10/6/2011 8:24 AM, Rolf Eike Beer wrote:
Bill, that Watcom stuff was introduced by you in
9891260a6dab66c9ea44b5c2e244f3128625baf5.
I simply assumed it was a debug leftover as setting a variable to the
value
it already has looks pretty pointless to me.
diff --git a/Tests/LoadCommand/CMakeCommands/CMakeLists.txt
b/Tests/LoadCommand/CMakeCommands/CMakeLists.txt
index 953d05c..5cdbc59 100644
--- a/Tests/LoadCommand/CMakeCommands/CMakeLists.txt
+++ b/Tests/LoadCommand/CMakeCommands/CMakeLists.txt
@@ -5,9 +5,6 @@ IF (MUDSLIDE_TYPE MATCHES MUCHO)
ADD_DEFINITIONS(-DMUCHO_MUDSLIDE)
ENDIF (MUDSLIDE_TYPE MATCHES MUCHO)
-IF(WATCOM)
- SET(CMAKE_C_FLAGS ${CMAKE_C_FLAGS})
-ENDIF(WATCOM)
Hmmm... It could be some sort of odd escape thing going on that an
extra pass by the CMake parser fixes... I guess we can push it into the
dashboard and see if it fails. I can not remember at this point, but
watcom is a picky odd compiler.
Is anyone going to pick this patch up?
Eike
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Why is this patch important?
Sometimes, some of the useless checking that we do in the CMake test
suite is to make sure there's better code coverage on the dashboard,
even if the results of checks are not used. I don't think that's the
case here... but there are sometime non-obvious reasons behind some of
the lines in our tests.
Since this is just in the test suite, I see no reason to rush it into
a release at the last minute.
(But if it's important to you, I'm willing to be convinced that it
should be in the release... But you'll have to convince me.)
Thanks,
David
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Fixes to ExternalProject and it's tests
On Tue, Nov 1, 2011 at 1:52 PM, Rolf Eike Beer e...@sf-mail.de wrote: These two patches address some issues I found: -ExternalProject_Add(... DEPENDS something) does not work if that something is not itself created by ExternalProject_Add(). Fixed and testcase added. -The testcases for ExternalProject fail to detect on my German system my Subversion version. We had the issue back in the FindSubversion.cmake some time again and fixed it there, no need to duplicate the old wrong code here. The patches are independent of each other. Greetings, Eike -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers I'm not convinced the DEPENDS patch makes things better... ExternalProject works best (and is easiest to think about) when it is used in a SuperBuild sort of scenario in which *all* the targets are ExternalProject targets. Encouraging users to mix EP targets and non-EP targets is a mistake, I think. While it is allowed and achievable to mix things, it is certainly not easy, and requires mucho understanding and thought. Besides, you can easily do an add_dependencies after adding an ExternalProject if it depends on something else in your build that is not an ExternalProject. I'm not dead set against the DEPENDS patch, but I don't see it as urgent. What do others here think? The subversion patch, though, looks pretty reasonable. I'll merge that and push to 'next' later today. Thanks, David -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] LoadCommand test: cleanup
On Mon, Oct 17, 2011 at 9:18 AM, Rolf Eike Beer e...@sf-mail.de wrote:
On 10/6/2011 8:24 AM, Rolf Eike Beer wrote:
Bill, that Watcom stuff was introduced by you in
9891260a6dab66c9ea44b5c2e244f3128625baf5.
I simply assumed it was a debug leftover as setting a variable to the
value it already has looks pretty pointless to me.
diff --git a/Tests/LoadCommand/CMakeCommands/CMakeLists.txt
b/Tests/LoadCommand/CMakeCommands/CMakeLists.txt
index 953d05c..5cdbc59 100644
--- a/Tests/LoadCommand/CMakeCommands/CMakeLists.txt
+++ b/Tests/LoadCommand/CMakeCommands/CMakeLists.txt
@@ -5,9 +5,6 @@ IF (MUDSLIDE_TYPE MATCHES MUCHO)
ADD_DEFINITIONS(-DMUCHO_MUDSLIDE)
ENDIF (MUDSLIDE_TYPE MATCHES MUCHO)
-IF(WATCOM)
- SET(CMAKE_C_FLAGS ${CMAKE_C_FLAGS})
-ENDIF(WATCOM)
Hmmm... It could be some sort of odd escape thing going on that an
extra pass by the CMake parser fixes... I guess we can push it into
the
dashboard and see if it fails. I can not remember at this point, but
watcom is a picky odd compiler.
Is anyone going to pick this patch up?
Why is this patch important?
Sometimes, some of the useless checking that we do in the CMake test
suite is to make sure there's better code coverage on the dashboard,
even if the results of checks are not used. I don't think that's the
case here... but there are sometime non-obvious reasons behind some of
the lines in our tests.
Since this is just in the test suite, I see no reason to rush it into
a release at the last minute.
(But if it's important to you, I'm willing to be convinced that it
should be in the release... But you'll have to convince me.)
Well, I don't think it's that important that you should do an extra test
or whatever for the next release. It's just that this code, well, looks
totally wrong. And I would like for this to eventually go upstream. No
problem if you put it in some branch and wait for it until the development
for 2.8.8 opens.
Otherwise this code just looks wrong (tm). If this actually changes
anything this looks like a real bug we should find better sooner than
later, no? ;)
About the coverage: I thought about this, but putting stuff in some
totally unrelated tests just doesn't feel right at all. We should try to
get some coverage e.g. for the CheckSymbolExists testcase that could prove
why this is broken for some gcc optimization settings so that the
FindThreads patch I sent didn't work. So if coverage is a problem this
should go into it's own test that clearly states what it is testing and
why and not being hidden in some other random test.
Greetings,
Eike
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Git fun
I used to be able to push directly to next, because I'm a Module maintainer. Now I get this: $ git push origin next Enter passphrase for key '/Users/jbigler/.ssh/id_rsa': Counting objects: 12, done. Delta compression using up to 2 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 1001 bytes, done. Total 7 (delta 5), reused 0 (delta 0) -- James Bigler jamesbig...@gmail.com may not push directly to this repository. Use the CMake Topic Stage to merge your topic: http://www.cmake.org/Wiki/CMake/Git#Topic_Stage -- error: hook declined to update refs/heads/next To g...@cmake.org:cmake.git ! [remote rejected] next - next (hook declined) error: failed to push some refs to 'g...@cmake.org:cmake.git' OK. So I tried to do a stage merge: $ git checkout CUDAv3.2PathChanges Switched to branch 'CUDAv3.2PathChanges' $ git push stage HEAD fatal: 'stage' does not appear to be a git repository fatal: The remote end hung up unexpectedly $ git branch * CUDAv3.2PathChanges master next topics/CudaRTEmuLibraryForCUDA30 topics/FindCUDA-allow-g3 topics/FixCudaVersionAfterFirstRun Can anyone help with with my ignorance of Git? The only thing I used Git for is CMake and I just don't use it enough to learn all the nooks and crannies of this tool. Thanks, James -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Git fun
James, You have not defined stage as the nickname for the remote repository. If you set it up with `git remote add stage g...@cmake.org:stage/cmake.git`, then your push syntax should work. Alternately, `git push g...@cmake.org:stage/cmake.git CUDAv3.2PathChanges` would push using the full name. Richard On Dec 5, 2011, at 4:41 PM, James Bigler wrote: I used to be able to push directly to next, because I'm a Module maintainer. Now I get this: $ git push origin next Enter passphrase for key '/Users/jbigler/.ssh/id_rsa': Counting objects: 12, done. Delta compression using up to 2 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 1001 bytes, done. Total 7 (delta 5), reused 0 (delta 0) -- James Bigler jamesbig...@gmail.com may not push directly to this repository. Use the CMake Topic Stage to merge your topic: http://www.cmake.org/Wiki/CMake/Git#Topic_Stage -- error: hook declined to update refs/heads/next To g...@cmake.org:cmake.git ! [remote rejected] next - next (hook declined) error: failed to push some refs to 'g...@cmake.org:cmake.git' OK. So I tried to do a stage merge: $ git checkout CUDAv3.2PathChanges Switched to branch 'CUDAv3.2PathChanges' $ git push stage HEAD fatal: 'stage' does not appear to be a git repository fatal: The remote end hung up unexpectedly $ git branch * CUDAv3.2PathChanges master next topics/CudaRTEmuLibraryForCUDA30 topics/FindCUDA-allow-g3 topics/FixCudaVersionAfterFirstRun Can anyone help with with my ignorance of Git? The only thing I used Git for is CMake and I just don't use it enough to learn all the nooks and crannies of this tool. Thanks, James -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Git fun
Thanks, that fixed it. I also updated the wiki page, so the next poor person to come along doesn't beat their head over it. http://www.cmake.org/Wiki/CMake/Git/Develop#Share_a_Topic James On Mon, Dec 5, 2011 at 3:57 PM, Richard Wackerbarth rich...@nfsnet.orgwrote: James, You have not defined stage as the nickname for the remote repository. If you set it up with `git remote add stage g...@cmake.org:stage/cmake.git`, then your push syntax should work. Alternately, `git push g...@cmake.org:stage/cmake.git CUDAv3.2PathChanges` would push using the full name. Richard On Dec 5, 2011, at 4:41 PM, James Bigler wrote: I used to be able to push directly to next, because I'm a Module maintainer. Now I get this: $ git push origin next Enter passphrase for key '/Users/jbigler/.ssh/id_rsa': Counting objects: 12, done. Delta compression using up to 2 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 1001 bytes, done. Total 7 (delta 5), reused 0 (delta 0) -- James Bigler jamesbig...@gmail.com may not push directly to this repository. Use the CMake Topic Stage to merge your topic: http://www.cmake.org/Wiki/CMake/Git#Topic_Stage -- error: hook declined to update refs/heads/next To g...@cmake.org:cmake.git ! [remote rejected] next - next (hook declined) error: failed to push some refs to 'g...@cmake.org:cmake.git' OK. So I tried to do a stage merge: $ git checkout CUDAv3.2PathChanges Switched to branch 'CUDAv3.2PathChanges' $ git push stage HEAD fatal: 'stage' does not appear to be a git repository fatal: The remote end hung up unexpectedly $ git branch * CUDAv3.2PathChanges master next topics/CudaRTEmuLibraryForCUDA30 topics/FindCUDA-allow-g3 topics/FixCudaVersionAfterFirstRun Can anyone help with with my ignorance of Git? The only thing I used Git for is CMake and I just don't use it enough to learn all the nooks and crannies of this tool. Thanks, James -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Git fun
On 12/5/2011 6:22 PM, James Bigler wrote: Thanks, that fixed it. I also updated the wiki page, so the next poor person to come along doesn't beat their head over it. http://www.cmake.org/Wiki/CMake/Git/Develop#Share_a_Topic Thanks. I missed that when writing the instructions. I updated your edit to put the one-time setup instructions up with the others at the top of the page and reference them from that step. Thanks, -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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Automatically pull in dependencies from QtDesigner plugins
On Sun, Dec 4, 2011 at 11:34 AM, Michael Jackson
mike.jack...@bluequartz.net wrote:
Do you have MyWidget packaged as a true library, or did you just create the
Designer Plugin and then have a loose .cpp/.h file?
The is a project called Qwt* that has a similar setup. It has a Designer
plugin for its various widgets and it has a qwt.dylib/.dll/.so that your
program links against. You might be able to use this type of workflow for
your project. In rough form this is what I am suggesting:
Create a MyWidget project that builds the Designer plugin and a dynamic
library. When the project installs it will install its headers and library
under its own install location and also install the Designer plugin into the
appropriate location inside the Qt distribution you are using. The MyWidget
would also include the necessary CMake EXPORT files or what ever so other
projects can use it.
In the project that actually _uses_ MyWidget, you call
find_package(MyWidget) which will setup all the necessary include
directories and MyWidget_LIBRARIES variables.
*Normal Qwt at Sourceforge does NOT use CMake as a build system. I have
created a CMake build system for Qwt which is located on my public git-web
server.
Hope some of that helps.
Thanks Mike,
I tried simply placing the Widget in a subdirectory called Widget. I
got it to work, but I am confused about one thing. If in the main
project CMakeLists.txt I add:
add_subdirectory(Widget)
and then in Widget/CMakeLists.txt I add:
include_directories(${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CURRENT_BINARY_DIR})
I get errors that LabeledSlider.h can't find ui_LabeledSlider.h, and
main.cpp can't find LabeledSlider.h (problems with uic). However, if
instead I add directly to the main project CMakeLists.txt:
include_directories(${CMAKE_CURRENT_BINARY_DIR}/Widget)
include_directories(${CMAKE_CURRENT_SOURCE_DIR}/Widget)
it works fine. Can you explain the difference between these two
methods of adding the include directories? I have setup both cases
here: http://daviddoria.com/Uploads/QtSubdirectory.tar.gz
Thanks,
David
--
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] Automatically pull in dependencies from QtDesigner plugins
On Dec 5, 2011, at 8:29 AM, David Doria wrote:
On Sun, Dec 4, 2011 at 11:34 AM, Michael Jackson
mike.jack...@bluequartz.net wrote:
Do you have MyWidget packaged as a true library, or did you just create
the Designer Plugin and then have a loose .cpp/.h file?
The is a project called Qwt* that has a similar setup. It has a Designer
plugin for its various widgets and it has a qwt.dylib/.dll/.so that your
program links against. You might be able to use this type of workflow for
your project. In rough form this is what I am suggesting:
Create a MyWidget project that builds the Designer plugin and a dynamic
library. When the project installs it will install its headers and library
under its own install location and also install the Designer plugin into the
appropriate location inside the Qt distribution you are using. The MyWidget
would also include the necessary CMake EXPORT files or what ever so other
projects can use it.
In the project that actually _uses_ MyWidget, you call
find_package(MyWidget) which will setup all the necessary include
directories and MyWidget_LIBRARIES variables.
*Normal Qwt at Sourceforge does NOT use CMake as a build system. I have
created a CMake build system for Qwt which is located on my public git-web
server.
Hope some of that helps.
Thanks Mike,
I tried simply placing the Widget in a subdirectory called Widget. I
got it to work, but I am confused about one thing. If in the main
project CMakeLists.txt I add:
add_subdirectory(Widget)
and then in Widget/CMakeLists.txt I add:
include_directories(${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CURRENT_BINARY_DIR})
I get errors that LabeledSlider.h can't find ui_LabeledSlider.h, and
main.cpp can't find LabeledSlider.h (problems with uic). However, if
instead I add directly to the main project CMakeLists.txt:
include_directories(${CMAKE_CURRENT_BINARY_DIR}/Widget)
include_directories(${CMAKE_CURRENT_SOURCE_DIR}/Widget)
it works fine. Can you explain the difference between these two
methods of adding the include directories? I have setup both cases
here: http://daviddoria.com/Uploads/QtSubdirectory.tar.gz
Thanks,
David
Basically you have to figure out where ui_LabeledSlider.h is being generated
and make sure that directory is being added via include_directories. Once you
work through that the other errors may go away.
Mike Jackson
--
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] Copy a input file from src folder to EXECUTABLE_OUTPUT_PATH
Hi, I have a tree of applications, some needing an inoput file to run. I have CMake compiling all of them and moving the executables to EXECUTABLE_OUTPUT_PATH. In the src directories, I have some input.txt files that I want to be moved to the same folder as the executables. How do I do that in CMake? thanks, Totte -- . Totte Karlsson, Ph.D. Dune Scientific, LLC 425-296 1980 (office) 425-780 9648 (cell) www.dunescientific.com . -- 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] Best practices/preferred methods for linking external libraries
On Dec 4, 2011, at 11:59 AM, Michael Jackson wrote: On Dec 1, 2011, at 4:56 PM, Matthew LeRoy wrote: We began using CMake a few months ago for a couple of small cross-platform projects, and we're still learning all the ins and outs and capabilities CMake has to offer, as well as how to get the most out of CMake by using it The Right Way. Right now, we're trying to figure out how to link to external libraries that don't have find modules or CMake config-mode files. After lots of reading in the wiki, mailing list, etc, it seems like there are several different ways to do this, like writing find modules and/or config-mode files ourselves, using the LINK_DIRECTORIES() command, importing/exporting targets, and others. What we're unsure of is, what is the preferred or officially supported method? To be a little more specific, we have two different library projects (call them ProjectA and ProjectB) that both use CMake, but are developed independently. Further, ProjectB depends (or will depend) on ProjectA; we've just recently gotten to the point on ProjectB where we want to use some of the functionality in ProjectA, so we need to link to the ProjectA library(ies). At first we thought we needed to write a find module for ProjectA -- but we really have very little idea how to go about doing that. Other than the wiki page for finding libraries that talks a little about writing find modules (http://www.vtk.org/Wiki/CMake:How_To_Find_Libraries), is there any other documentation for writing a proper find module? Is there a particular module that ships with CMake that is well-written that we should look at as a guide? I had a project that I developed a few years back which was very close to your situation. My project, call it MXA, was the base library that got used in a number of other projects. What I ended up doing was creating a FindMXA.cmake file that got configured during the actual build of MXA to make sure all the proper library names and location of resource files were set correctly. Then I would install the MXA project into an external location on my system, say /Users/Shared/Toolkits (OS X). I would manually copy the FindMXA.cmake file to the other projects so that they could have the find module available. In the beginning this made for a lot of manual copying when MXA was changing a bunch but once MXA settled down to a consistent naming scheme the FindMXA.cmake file never changed and so I found I did not have to update the FindMXA.cmake file in the other projects that depended on MXA. I think in more recent years the CMake developers would rather see people create the CMake Export files instead of developing the Find* module for my project. In the end I just didn't have the time to properly investigate and implement the CMake Export file so I never did it. I think if the CMake community took a vote we could probably come up with an Exemplar Find*.cmake file that is good for someone trying to develop a new one. The issues that arise are that each of the projects that have a Find*.cmake file are usually different in subtle ways which leads to issues when you try to simply copy/paste from an existing module to create a new module. It really just depends on what your ProjectA has installed. I am going to provide my current FindMXA.cmake file at the end of this email and leave it open for criticism/corrections. Maybe it will spur a conversation that we can all benefit from. Believe it or not, I've already been using your MXADataModel project as my main 'exemplar' CMake-based project. I had read several messages from you in the archives when I was first getting started with CMake, and I think at least one of them also mentioned MXA, so I went to your website and saw that the source was available so I thought I'd take a peek. Anyway, let me clarify a little bit what we're trying to accomplish. We are indeed trying to treat ProjectA and ProjectB as completely independent projects (as Alan has suggested), and our plan is to version ProjectA and do drops at specific milestones. ProjectB will use only the binary distribution of ProjectA. We would like to make it so that ProjectB's source tree in version control is entirely self-contained, so that we can simply sync down a local copy in a fresh development environment and compile without having to 'install' ProjectA first. Better yet, we may want to sync multiple copies of ProjectB's source tree in separate locations on the same system, from different instances in time where the version of ProjectA in use is different, and be able to build and debug both separate copies of ProjectB without having to worry about having multiple versions of ProjectA 'installed'. Our thought here is to have part of ProjectA's source tree be a collection of binary distribu tions of the various independent components that is uses - one of which is ProjectA. That
Re: [CMake] Best practices/preferred methods for linking external libraries
On Dec 5, 2011, at 5:36 PM, Matthew LeRoy wrote: On Dec 4, 2011, at 11:59 AM, Michael Jackson wrote: On Dec 1, 2011, at 4:56 PM, Matthew LeRoy wrote: We began using CMake a few months ago for a couple of small cross-platform projects, and we're still learning all the ins and outs and capabilities CMake has to offer, as well as how to get the most out of CMake by using it The Right Way. Right now, we're trying to figure out how to link to external libraries that don't have find modules or CMake config-mode files. After lots of reading in the wiki, mailing list, etc, it seems like there are several different ways to do this, like writing find modules and/or config-mode files ourselves, using the LINK_DIRECTORIES() command, importing/exporting targets, and others. What we're unsure of is, what is the preferred or officially supported method? To be a little more specific, we have two different library projects (call them ProjectA and ProjectB) that both use CMake, but are developed independently. Further, ProjectB depends (or will depend) on ProjectA; we've just recently gotten to the point on ProjectB where we want to use some of the functionality in ProjectA, so we need to link to the ProjectA library(ies). At first we thought we needed to write a find module for ProjectA -- but we really have very little idea how to go about doing that. Other than the wiki page for finding libraries that talks a little about writing find modules (http://www.vtk.org/Wiki/CMake:How_To_Find_Libraries), is there any other documentation for writing a proper find module? Is there a particular module that ships with CMake that is well-written that we should look at as a guide? I had a project that I developed a few years back which was very close to your situation. My project, call it MXA, was the base library that got used in a number of other projects. What I ended up doing was creating a FindMXA.cmake file that got configured during the actual build of MXA to make sure all the proper library names and location of resource files were set correctly. Then I would install the MXA project into an external location on my system, say /Users/Shared/Toolkits (OS X). I would manually copy the FindMXA.cmake file to the other projects so that they could have the find module available. In the beginning this made for a lot of manual copying when MXA was changing a bunch but once MXA settled down to a consistent naming scheme the FindMXA.cmake file never changed and so I found I did not have to update the FindMXA.cmake file in the other projects that depended on MXA. I think in more recent years the CMake developers would rather see people create the CMake Export files instead of developing the Find* module for my project. In the end I just didn't have the time to properly investigate and implement the CMake Export file so I never did it. I think if the CMake community took a vote we could probably come up with an Exemplar Find*.cmake file that is good for someone trying to develop a new one. The issues that arise are that each of the projects that have a Find*.cmake file are usually different in subtle ways which leads to issues when you try to simply copy/paste from an existing module to create a new module. It really just depends on what your ProjectA has installed. I am going to provide my current FindMXA.cmake file at the end of this email and leave it open for criticism/corrections. Maybe it will spur a conversation that we can all benefit from. Believe it or not, I've already been using your MXADataModel project as my main 'exemplar' CMake-based project. I had read several messages from you in the archives when I was first getting started with CMake, and I think at least one of them also mentioned MXA, so I went to your website and saw that the source was available so I thought I'd take a peek. Anyway, let me clarify a little bit what we're trying to accomplish. We are indeed trying to treat ProjectA and ProjectB as completely independent projects (as Alan has suggested), and our plan is to version ProjectA and do drops at specific milestones. ProjectB will use only the binary distribution of ProjectA. We would like to make it so that ProjectB's source tree in version control is entirely self-contained, so that we can simply sync down a local copy in a fresh development environment and compile without having to 'install' ProjectA first. Better yet, we may want to sync multiple copies of ProjectB's source tree in separate locations on the same system, from different instances in time where the version of ProjectA in use is different, and be able to build and debug both separate copies of ProjectB without having to worry about having multiple versions of ProjectA 'installed'. Our thought here is to have part of ProjectA's source tree be a collection of binary distri butions of the
Re: [CMake] Copy a input file from src folder to EXECUTABLE_OUTPUT_PATH
On 12/05/2011 10:30 PM, Totte Karlsson wrote:
Hi,
I have a tree of applications, some needing an inoput file to run. I have
CMake
compiling all of them and moving the executables to
EXECUTABLE_OUTPUT_PATH. In the src directories, I have some input.txt files
that
I want to be moved to the same folder as the executables.
How do I do that in CMake?
At configuration time:
CONFIGURE_FILE(path/to/input.txt ${EXECUTABLE_OUTPUT_PATH} COPYONLY)
Note that the destination directory, i.e. the EXECUTABLE_OUTPUT_PATH,
possibly must already exist, and refer to the EXECUTABLE_OUTPUT_PATH
variable only after it has received its value. BTW, this variable is
obsolete, use [CMAKE_]RUNTIME_OUTPUT_DIRECTORY[_CONFIG] variable/
properties instead.
At build time:
ADD_CUSTOM_TARGET(input ${CMAKE_COMMAND} -E copy_if_different
path/to/input.txt ${EXECUTABLE_OUTPUT_PATH})
ADD_DEPENDENCIES(OneOfYourExecutables input)
ADD_DEPENDENCIES(AnotherExecutable input)
or
ADD_CUSTOM_COMMAND(TARGET OneOfYourExecutables
COMMAND ${CMAKE_COMMAND} -E copy_if_different
path/to/input.txt $TARGET_FILE_DIR:OneOfYourExecutables)
ADD_CUSTOM_COMMAND(TARGET AnotherExecutable
COMMAND ${CMAKE_COMMAND} -E copy_if_different
path/to/input.txt $TARGET_FILE_DIR:AnotherExecutable)
Personally, I'd prefer the latter as it's clean and quite flexible.
Regards,
Michael
--
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.6-2103-gbf21aea
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 bf21aea45eaa1d714f21a18f232f61668cecae0a (commit) via 0efe602c595e78c5e7cef6c85dc7983be7a905df (commit) from af2d5df5bb8015c14ab754a07900605c3504b4d3 (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=bf21aea45eaa1d714f21a18f232f61668cecae0a commit bf21aea45eaa1d714f21a18f232f61668cecae0a Merge: af2d5df 0efe602 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Dec 5 09:00:38 2011 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Dec 5 09:00:38 2011 -0500 Merge topic 'TinyCC-compiler' into next 0efe602 TinyCC: Add default compilation flags (#12605) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0efe602c595e78c5e7cef6c85dc7983be7a905df commit 0efe602c595e78c5e7cef6c85dc7983be7a905df Author: Mathieu Malaterre mathieu.malate...@gmail.com AuthorDate: Sat Dec 3 12:21:48 2011 +0100 Commit: Brad King brad.k...@kitware.com CommitDate: Mon Dec 5 08:59:50 2011 -0500 TinyCC: Add default compilation flags (#12605) diff --git a/Modules/Compiler/TinyCC-C.cmake b/Modules/Compiler/TinyCC-C.cmake index bb27ead..4a48c0a 100644 --- a/Modules/Compiler/TinyCC-C.cmake +++ b/Modules/Compiler/TinyCC-C.cmake @@ -1 +1,8 @@ SET(CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS -shared) + +# no optimization in tcc: +SET (CMAKE_C_FLAGS_INIT ) +SET (CMAKE_C_FLAGS_DEBUG_INIT -g) +SET (CMAKE_C_FLAGS_MINSIZEREL_INIT -DNDEBUG) +SET (CMAKE_C_FLAGS_RELEASE_INIT -DNDEBUG) +SET (CMAKE_C_FLAGS_RELWITHDEBINFO_INIT -g) --- Summary of changes: Modules/Compiler/TinyCC-C.cmake |7 +++ 1 files changed, 7 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.6-2105-g91a2146
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 91a2146523c12683bb732b365ffadc9844e026ab (commit)
via f911bc94352888acc8cecb3e559fe3d3fba905b1 (commit)
from bf21aea45eaa1d714f21a18f232f61668cecae0a (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=91a2146523c12683bb732b365ffadc9844e026ab
commit 91a2146523c12683bb732b365ffadc9844e026ab
Merge: bf21aea f911bc9
Author: David Cole david.c...@kitware.com
AuthorDate: Mon Dec 5 11:46:58 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 5 11:46:58 2011 -0500
Merge topic 'findlapack-0012477' into next
f911bc9 Revert fixed: lapack static linkage (0012477)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f911bc94352888acc8cecb3e559fe3d3fba905b1
commit f911bc94352888acc8cecb3e559fe3d3fba905b1
Author: David Cole david.c...@kitware.com
AuthorDate: Mon Dec 5 11:39:31 2011 -0500
Commit: David Cole david.c...@kitware.com
CommitDate: Mon Dec 5 11:39:31 2011 -0500
Revert fixed: lapack static linkage (0012477)
This reverts commit 810675b3080db3f7dd4edc688106c8c769bbc107.
diff --git a/Modules/FindLAPACK.cmake b/Modules/FindLAPACK.cmake
index e1d1202..bccf789 100644
--- a/Modules/FindLAPACK.cmake
+++ b/Modules/FindLAPACK.cmake
@@ -106,7 +106,7 @@ endforeach(_library ${_list})
if(_libraries_work)
# Test this combination of libraries.
if(UNIX AND BLA_STATIC)
-set(CMAKE_REQUIRED_LIBRARIES ${_flags} -Wl,--start-group ${${LIBRARIES}}
${_blas} -Wl,--end-group ${_threads})
+set(CMAKE_REQUIRED_LIBRARIES ${_flags} -Wl,--start-group ${${LIBRARIES}}
${_blas};-Wl,--end-group ${_threads})
else(UNIX AND BLA_STATIC)
set(CMAKE_REQUIRED_LIBRARIES ${_flags} ${${LIBRARIES}} ${_blas}
${_threads})
endif(UNIX AND BLA_STATIC)
---
Summary of changes:
Modules/FindLAPACK.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.6-2107-ge140831
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 e140831177071b15d0e8aa6023604b2e1926df03 (commit)
via f44f053a52db8f78288705454a04e001b8f2c74c (commit)
from 91a2146523c12683bb732b365ffadc9844e026ab (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=e140831177071b15d0e8aa6023604b2e1926df03
commit e140831177071b15d0e8aa6023604b2e1926df03
Merge: 91a2146 f44f053
Author: David Cole david.c...@kitware.com
AuthorDate: Mon Dec 5 11:47:10 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 5 11:47:10 2011 -0500
Merge topic 'findlapack-0012477-new' into next
f44f053 FindLAPACK: Fix linking to static LAPACK on Unix (#12477)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f44f053a52db8f78288705454a04e001b8f2c74c
commit f44f053a52db8f78288705454a04e001b8f2c74c
Author: Alexey Ozeritsky aozerit...@gmail.com
AuthorDate: Fri Dec 2 15:14:52 2011 +0400
Commit: David Cole david.c...@kitware.com
CommitDate: Mon Dec 5 11:41:52 2011 -0500
FindLAPACK: Fix linking to static LAPACK on Unix (#12477)
diff --git a/Modules/FindLAPACK.cmake b/Modules/FindLAPACK.cmake
index bccf789..f88eed0 100644
--- a/Modules/FindLAPACK.cmake
+++ b/Modules/FindLAPACK.cmake
@@ -106,7 +106,7 @@ endforeach(_library ${_list})
if(_libraries_work)
# Test this combination of libraries.
if(UNIX AND BLA_STATIC)
-set(CMAKE_REQUIRED_LIBRARIES ${_flags} -Wl,--start-group ${${LIBRARIES}}
${_blas};-Wl,--end-group ${_threads})
+set(CMAKE_REQUIRED_LIBRARIES ${_flags} -Wl,--start-group ${${LIBRARIES}}
${_blas} -Wl,--end-group ${_threads})
else(UNIX AND BLA_STATIC)
set(CMAKE_REQUIRED_LIBRARIES ${_flags} ${${LIBRARIES}} ${_blas}
${_threads})
endif(UNIX AND BLA_STATIC)
---
Summary of changes:
Modules/FindLAPACK.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.6-2111-gde3cd51
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 de3cd51e3546648a7375173301500db44f2b2098 (commit)
via f529ddcea0228e6919ef09af8d7d8afa7f1e7c19 (commit)
via e0bc42aa4ff086e9c6976ab91ba924530df0bf72 (commit)
via e21e5cf289b79b7c260c93a19c52b63810a0efa3 (commit)
from e140831177071b15d0e8aa6023604b2e1926df03 (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=de3cd51e3546648a7375173301500db44f2b2098
commit de3cd51e3546648a7375173301500db44f2b2098
Merge: e140831 f529ddc
Author: David Cole david.c...@kitware.com
AuthorDate: Mon Dec 5 11:51:22 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 5 11:51:22 2011 -0500
Merge topic 'fix-ExternalProject-svn-issue' into next
f529ddc Tests: ExternalProject: Remove unnecessary 'svn --version' call
e0bc42a KWSys Nightly Date Stamp
e21e5cf KWSys Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f529ddcea0228e6919ef09af8d7d8afa7f1e7c19
commit f529ddcea0228e6919ef09af8d7d8afa7f1e7c19
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Tue Nov 1 18:38:52 2011 +0100
Commit: David Cole david.c...@kitware.com
CommitDate: Mon Dec 5 11:49:31 2011 -0500
Tests: ExternalProject: Remove unnecessary 'svn --version' call
This test will fail to get a proper version number if running on a (e.g.
German) localized system because the regular expression used to match the
Subversion version output does not match. Instead of duplicating code just
remove the local test altogether and use the version that
FindSubversion.cmake
already detects.
diff --git a/Tests/ExternalProject/CMakeLists.txt
b/Tests/ExternalProject/CMakeLists.txt
index 4a542d7..ac70129 100644
--- a/Tests/ExternalProject/CMakeLists.txt
+++ b/Tests/ExternalProject/CMakeLists.txt
@@ -343,13 +343,6 @@ endif()
# Only do svn tests with svn = version 1.2
#
if(do_svn_tests)
- execute_process(COMMAND ${Subversion_SVN_EXECUTABLE} --version
-OUTPUT_VARIABLE Subversion_VERSION_SVN
-OUTPUT_STRIP_TRAILING_WHITESPACE)
- string(REGEX REPLACE ^(.*\n)?svn, version ([.0-9]+).*
-\\2 Subversion_VERSION_SVN ${Subversion_VERSION_SVN})
- message(STATUS Subversion_VERSION_SVN='${Subversion_VERSION_SVN}')
-
if(Subversion_VERSION_SVN VERSION_LESS 1.2)
message(STATUS No ExternalProject svn tests with svn client less than
version 1.2)
set(do_svn_tests 0)
---
Summary of changes:
Source/kwsys/kwsysDateStamp.cmake|2 +-
Tests/ExternalProject/CMakeLists.txt |7 ---
2 files changed, 1 insertions(+), 8 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.6-2123-g1f5c6e6
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 1f5c6e61ffa19e9071993e9459c374cccb5fe216 (commit) via 62e223e8fab50e87a804efd822dc336577608a9d (commit) via 40c516783e1df141f3d4a8f6400e90da822395c1 (commit) via c207f5d3616efacdc4d91217f90609fd3679f116 (commit) via 9c0df72dc4b4e9403a3516390bc59f971ad1c3de (commit) via 174bf35fbbcb22636e538323c168ecbc33a7cb39 (commit) via 8507eaed1659d91709c41d34b351ea6a0585983e (commit) via 7ada172002e56d3900f4498a2f1bc2ffbc531816 (commit) via 3b93e266c0e6f0a58d813fc8ec7bc5810ace4827 (commit) via 47457159c70d031cfdb5704ce46166de5a26 (commit) via bde4edb6ab6501de42bdc167e027a9f5c5760244 (commit) via 74ab0f6aa409a9d3e90c91b1b1c7a6e4b865ed62 (commit) from de3cd51e3546648a7375173301500db44f2b2098 (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=1f5c6e61ffa19e9071993e9459c374cccb5fe216 commit 1f5c6e61ffa19e9071993e9459c374cccb5fe216 Merge: de3cd51 62e223e Author: Alexander Neundorf neund...@kde.org AuthorDate: Mon Dec 5 17:15:29 2011 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Dec 5 17:15:29 2011 -0500 Merge topic 'AutomocIncludedDotMocFileHandling' into next 62e223e automoc: add variable CMAKE_AUTOMOC_STRICT_MODE, to enable strict parsing 40c5167 automoc: accept even more .moc files in non-strict mode c207f5d automoc: also accept other files when .moc is included in non-strict mode 9c0df72 automoc: add a StrictParseCppFile(), which is only qmake-compatible 174bf35 automoc: move the code for finding headers into separate function 8507eae automoc: fix handling of included _p.moc files 7ada172 automoc: some more linebreaks for the warnings for better readability 3b93e26 automoc: add extra check whether the header contains Q_PRIVATE_SLOT 4745715 Add a test case for the use of Q_PRIVATE_SLOT. bde4edb automoc: add special handling for including basename_p.moc, with test 74ab0f6 automoc: move some code from the big parsing loop into separate functions diff --cc Modules/AutomocInfo.cmake.in index 2c7c724,293ba64..44f2da2 --- a/Modules/AutomocInfo.cmake.in +++ b/Modules/AutomocInfo.cmake.in @@@ -11,5 -10,5 +11,6 @@@ set(AM_QT_MOC_EXECUTABLE @QT_MOC_EXECU set(AM_CMAKE_CURRENT_SOURCE_DIR @CMAKE_CURRENT_SOURCE_DIR@/) set(AM_CMAKE_CURRENT_BINARY_DIR @CMAKE_CURRENT_BINARY_DIR@/) set(AM_QT_VERSION_MAJOR @QT_VERSION_MAJOR@ ) +set(AM_Qt5Core_VERSION_MAJOR @Qt5Core_VERSION_MAJOR@ ) set(AM_TARGET_NAME @_moc_target_name@) + set(AM_STRICT_MODE @_moc_strict_mode@) diff --cc Source/cmQtAutomoc.cxx index 65d3da3,77b724c..2aa1cf2 --- a/Source/cmQtAutomoc.cxx +++ b/Source/cmQtAutomoc.cxx @@@ -160,11 -200,11 +210,12 @@@ void cmQtAutomoc::SetupAutomocTarget(cm makefile-AddDefinition(_moc_incs, _moc_incs.c_str()); makefile-AddDefinition(_moc_defs, _moc_defs.c_str()); makefile-AddDefinition(_moc_compile_defs, _moc_compile_defs.c_str()); + makefile-AddDefinition(_moc_options, _moc_options.c_str()); makefile-AddDefinition(_moc_files, _moc_files.c_str()); makefile-AddDefinition(_moc_headers, _moc_headers.c_str()); + makefile-AddDefinition(_moc_strict_mode, strictMode ? TRUE : FALSE); - const char* cmakeRoot = makefile-GetDefinition(CMAKE_ROOT); + const char* cmakeRoot = makefile-GetSafeDefinition(CMAKE_ROOT); std::string inputFile = cmakeRoot; inputFile += /Modules/AutomocInfo.cmake.in; std::string outputFile = targetDir; http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=62e223e8fab50e87a804efd822dc336577608a9d commit 62e223e8fab50e87a804efd822dc336577608a9d Author: Alex Neundorf neund...@kde.org AuthorDate: Fri Dec 2 22:08:06 2011 +0100 Commit: Alex Neundorf neund...@kde.org CommitDate: Fri Dec 2 22:08:06 2011 +0100 automoc: add variable CMAKE_AUTOMOC_STRICT_MODE, to enable strict parsing Alex diff --git a/Modules/AutomocInfo.cmake.in b/Modules/AutomocInfo.cmake.in index 2dc3aa2..293ba64 100644 --- a/Modules/AutomocInfo.cmake.in +++ b/Modules/AutomocInfo.cmake.in @@ -11,3 +11,4 @@ set(AM_CMAKE_CURRENT_SOURCE_DIR @CMAKE_CURRENT_SOURCE_DIR@/) set(AM_CMAKE_CURRENT_BINARY_DIR @CMAKE_CURRENT_BINARY_DIR@/) set(AM_QT_VERSION_MAJOR @QT_VERSION_MAJOR@ ) set(AM_TARGET_NAME @_moc_target_name@) +set(AM_STRICT_MODE @_moc_strict_mode@) diff --git a/Source/cmQtAutomoc.cxx b/Source/cmQtAutomoc.cxx index aa8c6e2..77b724c 100644 --- a/Source/cmQtAutomoc.cxx +++ b/Source/cmQtAutomoc.cxx @@ -115,6 +115,12 @@ void cmQtAutomoc::SetupAutomocTarget(cmTarget* target)
[Cmake-commits] CMake branch, next, updated. v2.8.6-2127-g9150657
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 9150657a9684191df98f222c829dcc5ca45ad305 (commit)
via aa595440786dcd84cbca81410c76c0b170b3abac (commit)
from fc522a07d7c8b33d1c73a160657f8f8498819a7f (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=9150657a9684191df98f222c829dcc5ca45ad305
commit 9150657a9684191df98f222c829dcc5ca45ad305
Merge: fc522a0 aa59544
Author: James Bigler jamesbig...@gmail.com
AuthorDate: Mon Dec 5 18:30:42 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 5 18:30:42 2011 -0500
Merge topic 'topics/FindCUDA/linux-double-build' into next
aa59544 Reset dependency file list when a dependency disappeared.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aa595440786dcd84cbca81410c76c0b170b3abac
commit aa595440786dcd84cbca81410c76c0b170b3abac
Author: James Bigler jamesbig...@gmail.com
AuthorDate: Mon Dec 5 16:29:28 2011 -0700
Commit: James Bigler jamesbig...@gmail.com
CommitDate: Mon Dec 5 16:29:28 2011 -0700
Reset dependency file list when a dependency disappeared.
Fix a long outstanding bug when a file in the dependency list wasn't found.
This bug
wouldn't reset the dependencies, so the makefile would still want the
missing file when
building. The work around was to configure twice, but this is no longer
necessary.
diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake
index d5ef430..f696f2e 100644
--- a/Modules/FindCUDA.cmake
+++ b/Modules/FindCUDA.cmake
@@ -339,6 +339,8 @@ macro(CUDA_INCLUDE_NVCC_DEPENDENCIES dependency_file)
# output depend on the dependency file itself, which should cause the
# rule to re-run.
if(CUDA_NVCC_DEPEND_REGENERATE)
+set(CUDA_NVCC_DEPEND ${dependency_file})
+#message(Generating an empty dependency_file: ${dependency_file})
file(WRITE ${dependency_file} #FindCUDA.cmake generated file. Do not
edit.\n)
endif(CUDA_NVCC_DEPEND_REGENERATE)
---
Summary of changes:
Modules/FindCUDA.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.6-2133-g086ee2c
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 086ee2cb14b1744f8914f98d923ee9e43fbd4c08 (commit)
via ae62a1cd35fcd9be8d1beb11c864fbe417de429e (commit)
via afb00fef193b1000aa76e3a523899712065d53d0 (commit)
via 61e862986ae56e111533c21759a4e01a41968d1e (commit)
via a603250a132d3a38428b6c3e2f425c1a0b2c3878 (commit)
via ecd8414757368f45152f6e3e4841a5b3715fa2d3 (commit)
from 9150657a9684191df98f222c829dcc5ca45ad305 (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=086ee2cb14b1744f8914f98d923ee9e43fbd4c08
commit 086ee2cb14b1744f8914f98d923ee9e43fbd4c08
Merge: 9150657 ae62a1c
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Dec 5 18:42:51 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 5 18:42:51 2011 -0500
Merge topic 'GNU-to-MS' into next
ae62a1c Test CMAKE_GNUtoMS option in ExportImport on MinGW and MSys
afb00fe Add CMAKE_GNUtoMS option to convert GNU .dll.a to MS .lib
61e8629 Factor makefile generator link rule lookup into helper function
a603250 Load platform files that need to know the ABI when possible
ecd8414 Fortran: Detect pointer size in gfortran on MinGW
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ae62a1cd35fcd9be8d1beb11c864fbe417de429e
commit ae62a1cd35fcd9be8d1beb11c864fbe417de429e
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Dec 5 16:49:10 2011 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Dec 5 18:20:35 2011 -0500
Test CMAKE_GNUtoMS option in ExportImport on MinGW and MSys
diff --git a/Tests/ExportImport/CMakeLists.txt
b/Tests/ExportImport/CMakeLists.txt
index 2e01c50..ccfb894 100644
--- a/Tests/ExportImport/CMakeLists.txt
+++ b/Tests/ExportImport/CMakeLists.txt
@@ -22,6 +22,11 @@ else(CMAKE_CONFIGURATION_TYPES)
endif(CMAKE_BUILD_TYPE)
endif(CMAKE_CONFIGURATION_TYPES)
+if(MINGW OR MSYS)
+ # Test CMAKE_GNUtoMS whether we have VS or not.
+ set(ExportImport_GNUtoMS 1)
+endif()
+
configure_file(${ExportImport_SOURCE_DIR}/InitialCache.cmake.in
${ExportImport_BINARY_DIR}/InitialCache.cmake @ONLY)
diff --git a/Tests/ExportImport/InitialCache.cmake.in
b/Tests/ExportImport/InitialCache.cmake.in
index f920b1f..4893f70 100644
--- a/Tests/ExportImport/InitialCache.cmake.in
+++ b/Tests/ExportImport/InitialCache.cmake.in
@@ -12,3 +12,4 @@ SET(CMAKE_CXX_FLAGS_MINSIZEREL @CMAKE_CXX_FLAGS_MINSIZEREL@
CACHE STRING C++
SET(CMAKE_CXX_FLAGS_RELWITHDEBINFO @CMAKE_CXX_FLAGS_RELWITHDEBINFO@ CACHE
STRING C++ Flags)
SET(CMAKE_INSTALL_PREFIX @ExportImport_BINARY_DIR@/Root CACHE STRING
Installation Prefix)
SET(CMAKE_SKIP_RPATH ON CACHE BOOL No RPATH)
+SET(CMAKE_GNUtoMS @ExportImport_GNUtoMS@ CACHE BOOL CMAKE_GNUtoMS)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=afb00fef193b1000aa76e3a523899712065d53d0
commit afb00fef193b1000aa76e3a523899712065d53d0
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Dec 5 16:39:07 2011 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Dec 5 18:13:49 2011 -0500
Add CMAKE_GNUtoMS option to convert GNU .dll.a to MS .lib
Teach the Windows-GNU.cmake platform file to look for Visual Studio
tools matching the target ABI. Add an extra step to the link command
for shared libraries and executables that export symbols and on which a
new GNUtoMS property is set (initialized by the CMAKE_GNUtoMS option).
Tell the GNU linker to output a module definition (.def) file listing
exported symbols in addition to the GNU-format import library (.dll.a).
Pass the .def file to the MS lib tool to construct a MS-format DLL
import library (.lib).
Teach the install(TARGETS) command to install the MS import library next
to the GNU one. Teach the install(EXPORT) and export() command to set
the IMPORTED_IMPLIB property pointing at the import library to use the
import library matching the tools in the importing project.
diff --git a/.gitattributes b/.gitattributes
index d9d64d6..d21f1dd 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -8,6 +8,7 @@ configurecrlf=input
*.sh.in crlf=input
*.bat -crlf
+*.bat.in-crlf
*.dsp -crlf
*.dsptemplate -crlf
*.dsw -crlf
diff --git a/Modules/Platform/GNUtoMS_lib.bat.in
b/Modules/Platform/GNUtoMS_lib.bat.in
new file mode 100644
index 000..2da920a
--- /dev/null
+++ b/Modules/Platform/GNUtoMS_lib.bat.in
@@ -0,0 +1,3 @@
+@echo off
+call @CMAKE_GNUtoMS_BAT@
+lib /machine:@CMAKE_GNUtoMS_ARCH@ %*
diff --git
[Cmake-commits] CMake branch, next, updated. v2.8.6-2135-gc7d44f4
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 c7d44f4ce033ca8fa40bc18135fce938085224af (commit)
via 83d4eeadac5a656949127d4e2b67c4e973bbab48 (commit)
from 086ee2cb14b1744f8914f98d923ee9e43fbd4c08 (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=c7d44f4ce033ca8fa40bc18135fce938085224af
commit c7d44f4ce033ca8fa40bc18135fce938085224af
Merge: 086ee2c 83d4eea
Author: James Bigler jamesbig...@gmail.com
AuthorDate: Mon Dec 5 18:56:24 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 5 18:56:24 2011 -0500
Merge topic 'topics/FindCUDA/FixCUDAInUNCPath' into next
83d4eea Add work around for CUDA in UNC paths.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=83d4eeadac5a656949127d4e2b67c4e973bbab48
commit 83d4eeadac5a656949127d4e2b67c4e973bbab48
Author: James Bigler jamesbig...@gmail.com
AuthorDate: Mon Dec 5 16:54:06 2011 -0700
Commit: James Bigler jamesbig...@gmail.com
CommitDate: Mon Dec 5 16:54:06 2011 -0700
Add work around for CUDA in UNC paths.
Nvcc can emit '/path' instead of '//path' which can cause a lot of grief
later. We test
to see if the file exists, if it doesn't then we see if the file exists
with '/'
prepended. Files that don't exist won't be added to the list.
diff --git a/Modules/FindCUDA/make2cmake.cmake
b/Modules/FindCUDA/make2cmake.cmake
index 7fce167..d41b72d 100644
--- a/Modules/FindCUDA/make2cmake.cmake
+++ b/Modules/FindCUDA/make2cmake.cmake
@@ -54,13 +54,27 @@ if (${depend_text} MATCHES .+)
string(REGEX REPLACE ^ + file ${file})
-if(NOT IS_DIRECTORY ${file})
+# OK, now if we had a UNC path, nvcc has a tendency to only output the
first '/'
+# instead of '//'. Here we will test to see if the file exists, if it
doesn't then
+# try to prepend another '/' to the path and test again. If it still
fails remove the
+# path.
+
+if(NOT EXISTS ${file})
+ if (EXISTS /${file})
+set(file /${file})
+ else()
+message(WARNING Removing non-existant dependency file: ${file})
+set(file )
+ endif()
+endif()
+
+if(NOT IS_DIRECTORY ${file})
# If softlinks start to matter, we should change this to REALPATH. For
now we need
# to flatten paths, because nvcc can generate stuff like /bin/../include
instead of
# just /include.
get_filename_component(file_absolute ${file} ABSOLUTE)
list(APPEND dependency_list ${file_absolute})
-endif(NOT IS_DIRECTORY ${file})
+endif()
endforeach(file)
---
Summary of changes:
Modules/FindCUDA/make2cmake.cmake | 18 --
1 files changed, 16 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. v2.8.6-2137-g90456d3
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 90456d383fbd92593bf91337dd7f8e58342b6682 (commit)
via c3c7a0cfb84526693d33d7469719518aab91ff31 (commit)
from c7d44f4ce033ca8fa40bc18135fce938085224af (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=90456d383fbd92593bf91337dd7f8e58342b6682
commit 90456d383fbd92593bf91337dd7f8e58342b6682
Merge: c7d44f4 c3c7a0c
Author: James Bigler jamesbig...@gmail.com
AuthorDate: Mon Dec 5 19:16:55 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 5 19:16:55 2011 -0500
Merge topic 'topics/FindCUDA/Quote-fixes' into next
c3c7a0c Fixes for handling quotes in args and other places (Fix Bug 11726
and 12099).
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c3c7a0cfb84526693d33d7469719518aab91ff31
commit c3c7a0cfb84526693d33d7469719518aab91ff31
Author: James Bigler jamesbig...@gmail.com
AuthorDate: Mon Dec 5 17:16:05 2011 -0700
Commit: James Bigler jamesbig...@gmail.com
CommitDate: Mon Dec 5 17:16:05 2011 -0700
Fixes for handling quotes in args and other places (Fix Bug 11726 and
12099).
diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake
index d5ef430..df3b6be 100644
--- a/Modules/FindCUDA.cmake
+++ b/Modules/FindCUDA.cmake
@@ -707,7 +707,7 @@ find_package_handle_standard_args(CUDA
# Add include directories to pass to the nvcc command.
macro(CUDA_INCLUDE_DIRECTORIES)
foreach(dir ${ARGN})
-list(APPEND CUDA_NVCC_INCLUDE_ARGS_USER -I${dir})
+list(APPEND CUDA_NVCC_INCLUDE_ARGS_USER -I${dir})
endforeach(dir ${ARGN})
endmacro(CUDA_INCLUDE_DIRECTORIES)
@@ -736,13 +736,13 @@ macro(CUDA_GET_SOURCES_AND_OPTIONS _sources
_cmake_options _options)
arg STREQUAL SHARED OR
arg STREQUAL MODULE
)
- list(APPEND ${_cmake_options} ${arg})
+ list(APPEND ${_cmake_options} ${arg})
else()
if ( _found_options )
-list(APPEND ${_options} ${arg})
+list(APPEND ${_options} ${arg})
else()
# Assume this is a file
-list(APPEND ${_sources} ${arg})
+list(APPEND ${_sources} ${arg})
endif()
endif()
endforeach()
@@ -890,7 +890,7 @@ macro(CUDA_WRAP_SRCS cuda_target format generated_files)
get_directory_property(CUDA_NVCC_INCLUDE_DIRECTORIES INCLUDE_DIRECTORIES)
if(CUDA_NVCC_INCLUDE_DIRECTORIES)
foreach(dir ${CUDA_NVCC_INCLUDE_DIRECTORIES})
- list(APPEND CUDA_NVCC_INCLUDE_ARGS -I${dir})
+ list(APPEND CUDA_NVCC_INCLUDE_ARGS -I${dir})
endforeach()
endif()
@@ -956,7 +956,7 @@ macro(CUDA_WRAP_SRCS cuda_target format generated_files)
# Note that if we ever want CUDA_NVCC_FLAGS_CONFIG to be string (instead
of a list
# like it is currently), we can remove the quotes around the
# ${CUDA_NVCC_FLAGS_${config_upper}} variable like the
CMAKE_HOST_FLAGS_CONFIG variable.
-set(CUDA_NVCC_FLAGS_CONFIG
${CUDA_NVCC_FLAGS_CONFIG}\nset(CUDA_NVCC_FLAGS_${config_upper}
\${CUDA_NVCC_FLAGS_${config_upper}};;${CUDA_WRAP_OPTION_NVCC_FLAGS_${config_upper}}\))
+set(CUDA_NVCC_FLAGS_CONFIG
${CUDA_NVCC_FLAGS_CONFIG}\nset(CUDA_NVCC_FLAGS_${config_upper}
${CUDA_NVCC_FLAGS_${config_upper}} ;;
${CUDA_WRAP_OPTION_NVCC_FLAGS_${config_upper}}))
endforeach()
if(compile_to_ptx)
diff --git a/Modules/FindCUDA/run_nvcc.cmake b/Modules/FindCUDA/run_nvcc.cmake
index 7349da3..b31011c 100644
--- a/Modules/FindCUDA/run_nvcc.cmake
+++ b/Modules/FindCUDA/run_nvcc.cmake
@@ -55,25 +55,25 @@ if(NOT generated_file)
endif()
# Set these up as variables to make reading the generated file easier
-set(CMAKE_COMMAND @CMAKE_COMMAND@)
-set(source_file @source_file@)
-set(NVCC_generated_dependency_file @NVCC_generated_dependency_file@)
-set(cmake_dependency_file @cmake_dependency_file@)
-set(CUDA_make2cmake @CUDA_make2cmake@)
-set(CUDA_parse_cubin @CUDA_parse_cubin@)
-set(build_cubin @build_cubin@)
+set(CMAKE_COMMAND @CMAKE_COMMAND@) # path
+set(source_file @source_file@) # path
+set(NVCC_generated_dependency_file @NVCC_generated_dependency_file@) # path
+set(cmake_dependency_file @cmake_dependency_file@) # path
+set(CUDA_make2cmake @CUDA_make2cmake@) # path
+set(CUDA_parse_cubin @CUDA_parse_cubin@) # path
+set(build_cubin @build_cubin@) # bool
# We won't actually use these variables for now, but we need to set this, in
# order to force this file to be run again if it changes.
-set(generated_file_path @generated_file_path@)
-set(generated_file_internal @generated_file@)
-set(generated_cubin_file_internal @generated_cubin_file@)
+set(generated_file_path @generated_file_path@) # path
[Cmake-commits] CMake branch, next, updated. v2.8.6-2139-g29c74ef
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 29c74ef8b08bfe8103d1b9fe64955402cda108c7 (commit)
via 80e279d37c246fb2b3da5e3cf396bab51e8b8f6b (commit)
from 90456d383fbd92593bf91337dd7f8e58342b6682 (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=29c74ef8b08bfe8103d1b9fe64955402cda108c7
commit 29c74ef8b08bfe8103d1b9fe64955402cda108c7
Merge: 90456d3 80e279d
Author: James Bigler jamesbig...@gmail.com
AuthorDate: Mon Dec 5 21:02:30 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 5 21:02:30 2011 -0500
Merge topic 'topics/FindCUDA/Multi-dir-clash' into next
80e279d Make CUDA working directory unique for each target.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=80e279d37c246fb2b3da5e3cf396bab51e8b8f6b
commit 80e279d37c246fb2b3da5e3cf396bab51e8b8f6b
Author: James Bigler jamesbig...@gmail.com
AuthorDate: Mon Dec 5 19:00:00 2011 -0700
Commit: James Bigler jamesbig...@gmail.com
CommitDate: Mon Dec 5 19:00:00 2011 -0700
Make CUDA working directory unique for each target.
This allows you to have more than source file with the same name but
different
directories. The intermediate and configuration files are now in this same
directory.
diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake
index d5ef430..8750d30 100644
--- a/Modules/FindCUDA.cmake
+++ b/Modules/FindCUDA.cmake
@@ -809,6 +809,43 @@ function(CUDA_BUILD_SHARED_LIBRARY shared_flag)
endfunction()
##
+# Helper to avoid clashes of files with the same basename but different paths.
+# This doesn't attempt to do exactly what CMake internals do, which is to only
+# add this path when there is a conflict, since by the time a second collision
+# in names is detected it's already too late to fix the first one. For
+# consistency sake the relative path will be added to all files.
+function(CUDA_COMPUTE_BUILD_PATH path build_path)
+ #message(CUDA_COMPUTE_BUILD_PATH([${path}] ${build_path}))
+ # Only deal with CMake style paths from here on out
+ file(TO_CMAKE_PATH ${path} bpath)
+ if (IS_ABSOLUTE ${bpath})
+# Absolute paths are generally unnessary, especially if something like
+# FILE(GLOB_RECURSE) is used to pick up the files.
+file(RELATIVE_PATH bpath ${CMAKE_CURRENT_SOURCE_DIR} ${bpath})
+ endif()
+
+ # This recipie is from cmLocalGenerator::CreateSafeUniqueObjectFileName in
the
+ # CMake source.
+
+ # Remove leading /
+ string(REGEX REPLACE ^[/]+ bpath ${bpath})
+ # Avoid absolute paths by removing ':'
+ string(REPLACE : _ bpath ${bpath})
+ # Avoid relative paths that go up the tree
+ string(REPLACE ../ __/ bpath ${bpath})
+ # Avoid spaces
+ string(REPLACE _ bpath ${bpath})
+
+ # Strip off the filename. I wait until here to do it, since removin the
+ # basename can make a path that looked like path/../basename turn into
+ # path/.. (notice the trailing slash).
+ get_filename_component(bpath ${bpath} PATH)
+
+ set(${build_path} ${bpath} PARENT_SCOPE)
+ #message(${build_path} = ${bpath})
+endfunction()
+
+##
# This helper macro populates the following variables and setups up custom
# commands and targets to invoke the nvcc compiler to generate C or PTX source
# dependent upon the format parameter. The compiler is invoked once with -M
@@ -977,13 +1014,6 @@ macro(CUDA_WRAP_SRCS cuda_target format generated_files)
list(APPEND nvcc_flags -D${cuda_target}_EXPORTS)
endif()
- # Determine output directory
- if(CUDA_GENERATED_OUTPUT_DIR)
-set(cuda_compile_output_dir ${CUDA_GENERATED_OUTPUT_DIR})
- else()
-set(cuda_compile_output_dir ${CMAKE_CURRENT_BINARY_DIR})
- endif()
-
# Reset the output variable
set(_cuda_wrap_generated_files )
@@ -994,6 +1024,19 @@ macro(CUDA_WRAP_SRCS cuda_target format generated_files)
get_source_file_property(_is_header ${file} HEADER_FILE_ONLY)
if(${file} MATCHES .*\\.cu$ AND NOT _is_header)
+ # Determine output directory
+ cuda_compute_build_path(${file} cuda_build_path)
+ set(cuda_compile_intermediate_directory
${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/${cuda_target}.dir/${cuda_build_path})
+ if(CUDA_GENERATED_OUTPUT_DIR)
+set(cuda_compile_output_dir ${CUDA_GENERATED_OUTPUT_DIR})
+ else()
+if ( compile_to_ptx )
+ set(cuda_compile_output_dir ${CMAKE_CURRENT_BINARY_DIR})
+else()
+ set(cuda_compile_output_dir
[Cmake-commits] CMake branch, master, updated. v2.8.6-306-g759323a
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 759323ad0b93ba9b31eb736988df382d0cc1fe7f (commit) from e0bc42aa4ff086e9c6976ab91ba924530df0bf72 (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=759323ad0b93ba9b31eb736988df382d0cc1fe7f commit 759323ad0b93ba9b31eb736988df382d0cc1fe7f Author: KWSys Robot kwro...@kitware.com AuthorDate: Tue Dec 6 00:05:06 2011 -0500 Commit: KWSys Robot kwro...@kitware.com CommitDate: Tue Dec 6 00:05:06 2011 -0500 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index d11a0eb..280d3f3 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2011) SET(KWSYS_DATE_STAMP_MONTH 12) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 05) +SET(KWSYS_DATE_STAMP_DAY 06) --- 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
