[cmake-developers] Regression in language support infrastructure for CMake 2.8.10-rc3
On 2012-10-24 16:39-0400 David Cole wrote: The CMake 2.8.10 release candidate stream continues! This is the last RC unless somebody finds a critical, must-fix issue with it. As you know I have been distracted by CMake on Wine issues for some time, and that is probably going to continue for a while, but just to do my duty I just now tried a standard PLplot build on Linux with rc3, and I am sorry to say there is a serious regression in the language support infrastructure relative to 2.8.9. Our Ada and D language support are both fine with 2.8.9, but both crap out with rc3. You may recall that our language support uses a workaround for bug 9220 (which is _still_ my top-priority bug for each release since that workaround is far from perfect and doubles enabling time for each language). The workaround (suggested by you years ago) uses a temporary workaround project in language_tests/Language to check whether language support works for a particular language. If that workaround project succeeds (with all build files stored in language_tests/Language, PLplot goes ahead and enables that language for real, but if not, it warns the user of the language issue and what will be removed from PLplot as a result, and moves on rather than erroring out. That workaround is working for all languages other than Ada and D as well as it ever did, but I brought it up because you will see the ERROR messages in the attached file of the 2.8.10-rc3 cmake output (and similarly for 2.8.9 cmake output for comparison) from the workaround project and would otherwise be surprised that our build system survives those errors when they occur. Now on to the rc3 errors: The error messages for the simple workaround project to check Ada start with CMake Error: Could not find cmake module file:/home/software/plplot_svn/HEAD/build_dir/language_tests/Ada/CMakeFiles/2.8.10-rc3/CMakeAdaCompiler.cmake And the rc3 error messages for the simple workaround project to check D start with CMake Error: Could not open file for write in copy operation /CMakeDCompiler.cmake.tmp So it appears to me that locations have been changed for 2.8.10 where CMake language support expects configured and other files to be. I haven't really been following 2.8.10 development that closely, but has there been such an obviously backwards-incompatible change in how language support works? Of course, this is probably the most non-ideal moment to discover something like this for me because I am still in the middle of the CMake-Wine tests, and I am sure it is a non-ideal moment for you as well. But I really do think the 2.8.10 release should be delayed until this issue is sorted out. I am certainly willing to cooperate on this end in as timely a manner as possible with any tests/simple projects that help to figure this out. Of course, I am also willing to make any change the CMake developers feel is necessary (so long as it doesn't break Ada and D language support for older versions of CMake) in our Ada and D language support, but I think that is a last resort. After all, we have only made minor modifications to the D language Cmake approach given at http://www.dsource.org/projects/cmaked so, for example, a change to just our D language support is going to leave others out in the cold. For the Ada case, I am aware of at least one other major project that depends on Ada language support. (To help identify this project, there was a long discussion with Bill recently from this guy implementing the project, but I am too tired to look him up any better than that.) I don't know for sure that that project will be affected by this CMake-2.8.10 regression in language support, but it is likely. Finally we already have a simple but self-contained Ada test project which can be obtained by svn checkout \ https://plplot.svn.sourceforge.net/svnroot/plplot/branches/test_cmake/test_ada I have just confirmed that simple project works fine with 2.8.9 and does not work with 2.8.10-rc3 so perhaps the CMake developers should start with a checkout of that simple project to help figure out what has gone wrong. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ 2.8.10-rc3_cmake.out.gz Description: Binary data 2.8.9_cmake.out.gz Description: Binary data -- 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
[cmake-developers] [CMake 0013611]: SOURCE_GROUP doesn't use last match
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13611 == Reported By:tzeH Assigned To: == Project:CMake Issue ID: 13611 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-10-27 05:28 EDT Last Modified: 2012-10-27 05:28 EDT == Summary:SOURCE_GROUP doesn't use last match Description: I use a main CMake file and an include with source_group commands. Using the SOURCE_GROUP commands like this: SOURCE_GROUP( Tests\\Project REGULAR_EXPRESSION tests/Project/.* ) SOURCE_GROUP( Tests\\Project\\GUI REGULAR_EXPRESSION tests/Project/GUI/.* ) SOURCE_GROUP( Tests\\Project\\DSP REGULAR_EXPRESSION tests/Project/DSP/.* ) SOURCE_GROUP( Tests\\Project\\math REGULAR_EXPRESSION tests/Project/math/.* ) does not create three sub-folders as it should according to the documentation: If no group explicitly lists the file, the LAST group whose regular expression matches the file will be favored. Additional Information: Removing the first entry gives me three subfolders, but I want the files in tests/Project to be in a folder and not in Source Files. I found this with the Visual Studio 2010 generators. == Issue History Date ModifiedUsername FieldChange == 2012-10-27 05:28 tzeH New Issue == -- 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] Generator expressisons in target properties
On Tuesday, October 23, 2012 09:47:49 Brad King wrote:
On 10/23/2012 09:13 AM, Stephen Kelly wrote:
However, if the direct and transitive dependencies really must be kept
separate, that will have to be rethought anyway.
They do. A few years ago I went through major pain to drop uses of the
old GetLinkLibraries and use either GetOriginalLinkLibraries or results
from cmComputeLinkDepends wherever possible. It is necessary to keep
them separate because cmComputeLinkDepends needs to know exactly what
the user originally specified as direct dependencies in order to compute
the closure properly.
I think in order to finish this feature, I'll need to know more about why
the direct and indirect dependencies need to be kept separate. Can you give
more information?
I can't think of a reason to link a library based on whether
POSITION_INDEPENDENT_CODE is true or false for a target.
A package could provide a PIC and non-PIC version of a library and
pick one based on whether the target is PIC or not.
Something like this?
add_library(foo-pic SHARED ${foo_pic_srcs})
add_library(foo-nopic SHARED ${foo_nopic_srcs})
add_library(foo INTERFACE)
set_property(TARGET foo INTERFACE_LINK_LIBRARIES
$$BOOL:$TARGET_PROPERTY:POSITION_INDEPENDENT_CODE:foo-pic
$$NOT:$BOOL:$TARGET_PROPERTY:POSITION_INDEPENDENT_CODE:foo-nopic
)
Or this?
add_library(foo-pic SHARED IMPORTED)
set_property(foo-pic IMPORTED_LOCATION ...)
add_library(foo-nopic SHARED IMPORTED)
set_property(foo-nopic IMPORTED_LOCATION ...)
add_library(foo INTERFACE)
set_property(TARGET foo INTERFACE_LINK_LIBRARIES
$$BOOL:$TARGET_PROPERTY:POSITION_INDEPENDENT_CODE:foo-pic
$$NOT:$BOOL:$TARGET_PROPERTY:POSITION_INDEPENDENT_CODE:foo-nopic
)
In somewhat more concrete terms, maybe if the STD_CXX11 property ever
becomes a reality, a library built with c++11 might require that
downstreams also use c++11 because of binary compatibility concerns in
the stdlib
IMO that should be a detect-and-reject case rather than propagated:
CMake Error ...:
Target foo has STD_CXX11=OFF but links bar with STD_CXX11=ON.
Just like PIC and WIN32 a package can provide multiple libraries and
select them conditionally on the needs of the final target.
I thought more about this, and I realized that it's counter to my goals for
Qt. My goal is for this to work on all platforms and all Qt configurations:
find_pacakge(Qt5Widgets REQUIRED)
add_executable(foo main.cpp)
target_link_libraries(foo Qt5::Widgets)
So, to satisfy the 'all platforms' part of the goal, Qt5::Widgets needs to
know to link to qtmain.lib on Windows. That is not counter to what you said.
However, the default configuration of Qt requires that
POSITION_INDEPENDENT_CODE is ON. I would want that to be part of the
interface of Qt5::Widgets too in the above example. This part is counter to
what you said. It is the opposite of detect-and-reject.
Another related thing I would like to be able to do is this:
try_compile(_compile_result ${CMAKE_BINARY_DIR}
#include QGlobal\n int main(int,char**) { return 0; }
TARGETS Qt5::Core
OUTPUT_VARIABLE _compile_output_var)
That is, add a TARGETS component to the try_compile signature to specify the
contents of the target_link_libraries line in the code generated by try
compile. (As a side note, I'd also like to extend try_compile so that it
really only tries to compile with a COMPILE_ONLY option or so).
In KDE, a try_compile like that is used to determine if Qt is compiled with
hidden visibility.
Currently, we have to specify CMAKE_POSITION_INDEPENDENT_CODE ON globally to
be able to use try_compile with anything Qt 5 related. That's not 'target-
orientated', so I'd prefer to be able to remove the global use of
CMAKE_POSITION_INDEPENDENT_CODE and make target-orientation part of the
design goals here.
That would require something like
set_property(TARGET Qt5::Core INTERFACE_POSITION_INDEPENDENT_CODE ON)
I think the general philosophy is that the final target should specify
how it wants to build and the libraries it links evaluate their exprs
to meet its requirements. If they can't then it is an error.
I propose a different algorithm. Something similar to this:
For each target to build:
compute the link closure
populate a container of target properties which \
appeared in generator expressions while \
computing the closure. [1]
For each property that has an INTERFACE_ variant:
# eg, WIN32, CXX11, PIC
If the property is set:
try to evaluate it as a generator expression
if a property from [1] is encountered:
raise an error.
else:
for each target in the link closure:
evaluate the INTERFACE_ variant of the property as a genex
if uses $TARGET_PROPERTY:LINK_LIBRARIES:
raise an error.
The end-value is property-specific. Some
Re: [CMake] CPack issue with long path names being misplaced in TGZ file
On Fri, Oct 26, 2012 at 7:45 PM, Eric Noulard eric.noul...@gmail.com wrote: 2012/10/27 Marcus Bartholomeu cm...@tecativa.com.br: I'm VERY sorry to bug you guys! I just realized that this is an issue with the midnight commander. It is not reading inside tarballs correctly. But CPack is creating the tarball correctly. Sorry again, Don't be, those bugs that are solving themselves after some time are my favourite ones :-] They are my favorite, too! Be aware, though, that Windows does have a 250-something character limitation on full paths, and if you have very long paths to the files in your project, you will eventually run into problems due to that limit. HTH, David -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- 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] Adding to RUN_TESTS target
Just run ctest down in the sub-directory, any directory with a
CTestTestfile.cmake file in it, (run it with no arguments), and it
will run the tests in that directory.
With Visual Studio, you'll need to use ${CMAKE_CTEST_COMMAND} -C
${CMAKE_CFG_INTDIR} as the custom command to get the tests to run for
the right configuration.
I would do something like this if I were going to do it:
add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/SubdirTests.log
${CMAKE_CTEST_COMMAND} -C ${CMAKE_CFG_INTDIR} -O
${CMAKE_BINARY_DIR}/SubdirTests.log
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/Subdir
)
add_custom_target(SubdirTests DEPENDS ${CMAKE_BINARY_DIR}/SubdirTests.log)
Then you could build the SubdirTests target to run the tests.
Of course, if you need to extend the subset, you could run a script as
the test suite instead, and in the script, do your pre-stuff, run
the ctest tests with the same command as above, and then do your
post-stuff.
Cheers,
David
On Wed, Oct 24, 2012 at 7:23 PM, Robert Dailey rcdailey.li...@gmail.com wrote:
Thanks David.
I don't mind creating a custom target for this, but I'm not sure how
to invoke CTest manually with the tests in question. What commands
would I run?
On Wed, Oct 24, 2012 at 6:15 PM, David Cole david.c...@kitware.com wrote:
The ctest command that is run by RUN_TESTS is not extensible at the moment.
However, you can use add_custom_target to make your own test target
(just don't name it test or RUN_TESTS... ;-) which can do whatever
you want.
HTH,
David
On Wed, Oct 24, 2012 at 5:44 PM, Robert Dailey rcdailey.li...@gmail.com
wrote:
Can I extend RUN_TESTS to execute more tests of my choosing? RUN_TESTS
will only execute tests defined in the directory of the project I
opened or below. I want to add some tests to it that are created prior
to that project.
--
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
[CMake] FrameworkCMakeToolkit
Hello everyone! I did some generic CMake scripts to more easier build C/C++ projects. Those scripts permits to build static library, build executable, build cxxtest, generate Doxygen Documentation in html, latex and pdf formats, create source, binary and documentation (just the pdf file) packages, to profile the code with GProf (only on Unix system). You can use those scripts on multiple projects in different tree. I put some examples to show how we can build projects. You can download it on Github: git://github.com/Athius/FrameworkCMakeToolkit.git As you can see, my english is not very good so if the documentation is not understandable, please feel free to tell me what I need to fix ;) If you have some questions/suggestions, don't hesitate to contact me! I hope those scripts can help some people ^^! Regards, Romain. -- 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.9-1221-gfab4dc7
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 fab4dc7c79fd72ac1d516dad6cd03dda58c52f1f (commit)
via 633f67c84fb0276563b186536cbeb6de5cb1d5aa (commit)
via 4322816b6b15746c191d55fdbffc62778f9d052a (commit)
via b2c631c7c84cd7ea77cfd3bdb6a3a42c8553025f (commit)
from 403da25e38c24a2631425d79f6c74498f56bcabd (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=fab4dc7c79fd72ac1d516dad6cd03dda58c52f1f
commit fab4dc7c79fd72ac1d516dad6cd03dda58c52f1f
Merge: 403da25 633f67c
Author: Clinton Stimpson clin...@elemtech.com
AuthorDate: Sat Oct 27 13:21:58 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sat Oct 27 13:21:58 2012 -0400
Merge topic 'packagemaker-component-postflight' into next
633f67c PackageMaker: Enable postflight script in component mode.
4322816 CMake Nightly Date Stamp
b2c631c CMake Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=633f67c84fb0276563b186536cbeb6de5cb1d5aa
commit 633f67c84fb0276563b186536cbeb6de5cb1d5aa
Author: Clinton Stimpson clin...@elemtech.com
AuthorDate: Sat Oct 27 11:07:31 2012 -0600
Commit: Clinton Stimpson clin...@elemtech.com
CommitDate: Sat Oct 27 11:20:44 2012 -0600
PackageMaker: Enable postflight script in component mode.
Previously, setting CPACK_POSTFLIGHT_SCRIPT had no effect in
component mode, when CPACK_COMPONENTS_ALL was set.
In component mode, a .mpkg is created that contains multiple .pkg's.
Because postflight scripts only work in a .pkg, add another .pkg to the
.mpkg and put the postflight script in that.
This is the same approach taken by the PackageMaker GUI when adding
a postflight script to a metapackage.
This fixes bug #12375.
diff --git a/Source/CPack/cmCPackComponentGroup.h
b/Source/CPack/cmCPackComponentGroup.h
index 48d935c..abae372 100644
--- a/Source/CPack/cmCPackComponentGroup.h
+++ b/Source/CPack/cmCPackComponentGroup.h
@@ -42,7 +42,9 @@ public:
class cmCPackComponent
{
public:
- cmCPackComponent() : Group(0), TotalSize(0) { }
+ cmCPackComponent() : Group(0), IsRequired(true), IsHidden(false),
+ IsDisabledByDefault(false), IsDownloaded(false),
+ TotalSize(0) { }
/// The name of the component (used to reference the component).
std::string Name;
diff --git a/Source/CPack/cmCPackPackageMakerGenerator.cxx
b/Source/CPack/cmCPackPackageMakerGenerator.cxx
index edbe838..ce3d0c9 100644
--- a/Source/CPack/cmCPackPackageMakerGenerator.cxx
+++ b/Source/CPack/cmCPackPackageMakerGenerator.cxx
@@ -106,56 +106,100 @@ int cmCPackPackageMakerGenerator::PackageFiles()
resDir += /en.lproj;
}
-
- // Create directory structure
- std::string preflightDirName = resDir + /PreFlight;
- std::string postflightDirName = resDir + /PostFlight;
const char* preflight = this-GetOption(CPACK_PREFLIGHT_SCRIPT);
const char* postflight = this-GetOption(CPACK_POSTFLIGHT_SCRIPT);
const char* postupgrade = this-GetOption(CPACK_POSTUPGRADE_SCRIPT);
- // if preflight or postflight scripts not there create directories
- // of the same name, I think this makes it work
- if(!preflight)
+
+ if(this-Components.empty())
{
-if ( !cmsys::SystemTools::MakeDirectory(preflightDirName.c_str()))
+// Create directory structure
+std::string preflightDirName = resDir + /PreFlight;
+std::string postflightDirName = resDir + /PostFlight;
+// if preflight or postflight scripts not there create directories
+// of the same name, I think this makes it work
+if(!preflight)
{
- cmCPackLogger(cmCPackLog::LOG_ERROR,
-Problem creating installer directory:
- preflightDirName.c_str() std::endl);
- return 0;
+ if ( !cmsys::SystemTools::MakeDirectory(preflightDirName.c_str()))
+{
+cmCPackLogger(cmCPackLog::LOG_ERROR,
+ Problem creating installer directory:
+ preflightDirName.c_str() std::endl);
+return 0;
+}
+ }
+if(!postflight)
+ {
+ if ( !cmsys::SystemTools::MakeDirectory(postflightDirName.c_str()))
+{
+cmCPackLogger(cmCPackLog::LOG_ERROR,
+ Problem creating installer directory:
+ postflightDirName.c_str() std::endl);
+return 0;
+}
+ }
+// if preflight, postflight, or postupgrade are set
+// then copy them into the resource directory and make
+// them executable
+if(preflight)
+ {
+
[Cmake-commits] CMake branch, next, updated. v2.8.9-1223-g47df2f5
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 47df2f5509e8b2326fe541ae7a24681c3a245865 (commit)
via a2e917f7642146bc74a232092b622da1f0c6dc65 (commit)
from fab4dc7c79fd72ac1d516dad6cd03dda58c52f1f (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=47df2f5509e8b2326fe541ae7a24681c3a245865
commit 47df2f5509e8b2326fe541ae7a24681c3a245865
Merge: fab4dc7 a2e917f
Author: Clinton Stimpson clin...@elemtech.com
AuthorDate: Sat Oct 27 22:59:44 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sat Oct 27 22:59:44 2012 -0400
Merge topic 'packagemaker-component-postflight' into next
a2e917f PackageMaker: Fix KWStyle failures from previous commit.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a2e917f7642146bc74a232092b622da1f0c6dc65
commit a2e917f7642146bc74a232092b622da1f0c6dc65
Author: Clinton Stimpson clin...@elemtech.com
AuthorDate: Sat Oct 27 20:59:08 2012 -0600
Commit: Clinton Stimpson clin...@elemtech.com
CommitDate: Sat Oct 27 20:59:08 2012 -0600
PackageMaker: Fix KWStyle failures from previous commit.
diff --git a/Source/CPack/cmCPackPackageMakerGenerator.cxx
b/Source/CPack/cmCPackPackageMakerGenerator.cxx
index ce3d0c9..c617a3e 100644
--- a/Source/CPack/cmCPackPackageMakerGenerator.cxx
+++ b/Source/CPack/cmCPackPackageMakerGenerator.cxx
@@ -182,11 +182,12 @@ int cmCPackPackageMakerGenerator::PackageFiles()
if (!cmsys::SystemTools::MakeDirectory(packageFileDir.c_str()))
{
cmCPackLogger(cmCPackLog::LOG_ERROR,
-Problem creating component PostFlight Packages directory:
+ Problem creating component PostFlight Packages directory:
packageFileDir.c_str() std::endl);
return 0;
}
-std::string packageFile = packageFileDir +
this-GetPackageName(PostFlightComponent);
+std::string packageFile = packageFileDir +
+ this-GetPackageName(PostFlightComponent);
if (!this-GenerateComponentPackage(packageFile.c_str(),
packageDir.c_str(),
PostFlightComponent))
@@ -824,8 +825,8 @@ WriteDistributionFile(const char* metapackageFile)
}
if(!this-PostFlightComponent.Name.empty())
{
- choiceOut line choice=\ PostFlightComponent.Name
Choice\/line
- std::endl;
+ choiceOut line choice=\ PostFlightComponent.Name
+ Choice\/line std::endl;
}
choiceOut /choices-outline std::endl;
---
Summary of changes:
Source/CPack/cmCPackPackageMakerGenerator.cxx |9 +
1 files changed, 5 insertions(+), 4 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.9-597-gabe4edf
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 abe4edfad3c6e8c2f2e9c08117507089790b303b (commit) from 4322816b6b15746c191d55fdbffc62778f9d052a (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=abe4edfad3c6e8c2f2e9c08117507089790b303b commit abe4edfad3c6e8c2f2e9c08117507089790b303b Author: Kitware Robot kwro...@kitware.com AuthorDate: Sun Oct 28 00:01:09 2012 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Sun Oct 28 00:01:09 2012 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index ef5c70f..0bddb7a 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,5 +2,5 @@ set(CMake_VERSION_MAJOR 2) set(CMake_VERSION_MINOR 8) set(CMake_VERSION_PATCH 9) -set(CMake_VERSION_TWEAK 20121027) +set(CMake_VERSION_TWEAK 20121028) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.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
