[cmake-developers] [CMake 0012245]: Watcom WLIB Needs case sensitive option
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12245
==
Reported By:d3x0r
Assigned To:
==
Project:CMake
Issue ID: 12245
Category: CMake
Reproducibility:always
Severity: major
Priority: urgent
Status: new
==
Date Submitted: 2011-06-04 03:04 EDT
Last Modified: 2011-06-04 03:04 EDT
==
Summary:Watcom WLIB Needs case sensitive option
Description:
WLIB does not generate proper exports if two routines have the same spelling and
different cases (like Scale and scale).
wlib has a -c option which makes it respect case when building the export
library from the dll.
SET(CMAKE_C_CREATE_IMPORT_LIBRARY
- wlib -q -n -b TARGET_IMPLIB +'TARGET_UNQUOTED')
SET(CMAKE_C_CREATE_IMPORT_LIBRARY
+ wlib -c -q -n -b TARGET_IMPLIB +'TARGET_UNQUOTED')
and
-SET(CMAKE_CXX_CREATE_STATIC_LIBRARY wlib ${CMAKE_LIB_QUIET} -n -b
'TARGET_UNQUOTED' LINK_FLAGS OBJECTS )
+SET(CMAKE_CXX_CREATE_STATIC_LIBRARY wlib ${CMAKE_LIB_QUIET} -c -n -b
'TARGET_UNQUOTED' LINK_FLAGS OBJECTS )
(ie - find 'wlib' in modules/platform/Windows-wcl386.cmake and insert a -c
option; it occurs in two places working on checking out the source to attach
a proper diff.
Steps to Reproduce:
(should be apparent)
==
Issue History
Date ModifiedUsername FieldChange
==
2011-06-04 03:04 d3x0r New Issue
==
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Getting some stuff from KDE into cmake
Hi, I'm currently at the KDE Platform Sprint, where we (a bunch of KDE developers) are discussing how to move on with the KDE platform. This includes some things regarding cmake. When we introduced cmake in KDE, there were not that many other free projects using cmake, so our cmake extensions was added to kdelibs, so all users of kdelibs have it available. The situation has changed in the last 5 years, and now more and more projects before kdelibs are using cmake, and they'd like to have some of those things available too. So there is a string wish to get some of our cmake stuff upstreamed, some parts up into cmake, and some parts only half way up. So what I'm doing now is I'll write for each wish we have an email here, and it would be nice if you could check whether whether each one sounds reasonable or not. I am here at the sprint until Tuesday, so until then I'll have basically 4 full days to work on the stuff. After that it'll be again only one or two hours in the evenings... Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Automoc in cmake
Hi,
one feature which all KDE developers are used to and which is also used by
qmake when building Qt is automoc.
This means that you don't have to write
qt4_wrap_cpp(srcs ${filesToBeMoced})
but instead you simply do
kde4_add_executable(hello ${srcs})
and everything including moc is handled automatically.
This is done so that in your foo.cpp file you include the moc-file e.g. at the
end:
---
Foo::Foo()
:QObject()
{
}
...
void Foo::doSomething()
{
}
#include foo.moc
What needs to be done for this is to parse all source files for such include
lines at build time (because such a line may have been inserted without
changing anything in CMakeLists.txt) and if such a line is found, moc has to
be started and the file has to be generated.
Currently this is done by the tool automoc4 which is a separate package.
It consists of a binary automoc4 and a macro
automoc_add_executable().
What this macro basically does is to add for each target foo an additional
target foo_automoc, and make the target foo depend on foo_automoc. So
foo_automoc is always built before foo.
The custom target foo_automoc basically runs the automoc4 executable, which
checks for all source files whether they have changed, and whether they
contain moc-include statements, and if so, it runs moc.
So, we'd like to have that available in cmake.
I see two ways how to do it:
1) keep the mechanism as it is, but integrate the functionality of the automoc
executable into cmake, so that the custom target would do cmake --automoc or
something like this.
This would still need an additional macro, which would then probably be
qt_add_executable().
When doing automoc, the list of source files has to be known, the include
directories and the defines.
This is currently written into a file which is then loaded by automoc4.
When integrating it this way, this would probably stay more or less like this.
2) Integrate it fully into cmake, i.e. add arguments to add_executable() and
add_library(), so I can do
add_executable(foo AUTOMOC ${srcs} )
Advantages of this would be that it doesn't need an extra macro and extra
custom target to be set up, and that the information like the list of files
and include directories is directly available in cmAddExecutable, so it
doesn't have to be written in a separate file which is read later on.
So, we'd really like to have that integrated in cmake.
What do you think ? Which way would you prefer ? I think I'm favouring option
2).
I'll work in the next days on porting current automoc away from using Qt to
plain STL (and kwsys), so that it becomes ready for inclusion. It is also
already BSD licensed.
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Adding argument OPTIONAL to find_package() and add_subdirectory
Hi, again from the KDE sprint... 1) We have a macro macro_optional_find_package(). The purpose is to be able to build without a specific package even if that package is installed and would actually be found by the find_package() call. Basically this is a wrapper around find_package(), but additionally it adds an option WITH_Foo, which is enabled by default. If disabled, the actual find_package() is not executed, and the variables FOO_FOUND/INCLUDES/LIBRARIES are reset to empty, so that even if the package hasn't been searched this time, results from previous runs are discarded. What do you think about adding this as a built-in feature to find_package(), i.e. add a argument OPTIONAL to find_package(), then probably also a COMMENT. 2) we have something similar for add_subdirectory(), macro_optional_add_subdirectory(). The purpose is to disable parts of a big project by skipping the add_subdirectory. This is a wrapper around add_subdirectory(), but adds an option BUILD_FOO, which is enabled by default. If disabled, the actual add_subdirectory() is not executed. Additionally there is an additional global option DISABLE_ALL_OPTIONAL_SUBDIRECTORIES, which is disabled by default. If enabled, all these optional subdirectories are disabled (but can be enabled again one by one). What do you think about adding the keyword OPTIONAL to add_subdirectory ? Both have been proven useful, the one for find_package() especially for packagers. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012246]: CMake NMake generator /machine defect
The following issue has been SUBMITTED. == http://www.vtk.org/Bug/view.php?id=12246 == Reported By:Thomas Laguzzi Assigned To: == Project:CMake Issue ID: 12246 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-06-04 06:35 EDT Last Modified: 2011-06-04 06:35 EDT == Summary:CMake NMake generator /machine defect Description: I have found a way to reproduce http://www.vtk.org/Bug/view.php?id=10695 where building with Nmake causes link failure No argument passed to /machine: The problem comes when the user does wrong the first NMake configuration Steps to Reproduce: 1- Open cmake-gui without compiler environment variables (i.e. open from Start-Run...) 2- Configure a project with NMake . You will get errors complaining about not finding the compiler 3- Close cmake-gui 4- Run cmake-gui from a VS command prompt 5- Configure (without deleting cache). This time the compiler is found. 6- Build - get the error Additional Information: It seems that the /machine: flag is not re-set in successive configurations even when the first failed. Not an important bug, but can block beginners == Issue History Date ModifiedUsername FieldChange == 2011-06-04 06:35 Thomas Laguzzi New Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Creating a separate project/package which provides cmake extensions/modules
Hi, again from the KDE sprint... We have around 150 cmake modules in kdelibs... Several libraries are not before kdelibs, so they don't have access to those. So, what we came up with is that create a new package which just contains our cmake modules, so they can be used by non-KDE applications. Of course, there we will also have to care about source compatibility and e.g. the required cmake version. So this is a middle ground between having this stuff in kdelibs and getting it completely upstreamed into cmake. I just noticed that there is https://github.com/rpavlik/cmake-modules . Maybe we can simple contribute to that one. I'll get in contact and we'll see what comes out of it. Do you think this is a reasonable plan or do you see conceptual issues with it ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Creating a separate project/package which provides cmake extensions/modules
Hi, Sounds reasonable to me. It reminds me th autoconf archive project. Also, I have always been doing the same: keep my cmake modules in a separate repository which is added as a submodule in all my others projects. -Nico On Saturday, June 4, 2011, Alexander Neundorf neund...@kde.org wrote: Hi, again from the KDE sprint... We have around 150 cmake modules in kdelibs... Several libraries are not before kdelibs, so they don't have access to those. So, what we came up with is that create a new package which just contains our cmake modules, so they can be used by non-KDE applications. Of course, there we will also have to care about source compatibility and e.g. the required cmake version. So this is a middle ground between having this stuff in kdelibs and getting it completely upstreamed into cmake. I just noticed that there is https://github.com/rpavlik/cmake-modules . Maybe we can simple contribute to that one. I'll get in contact and we'll see what comes out of it. Do you think this is a reasonable plan or do you see conceptual issues with it ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Nicolas Desprès ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
Hi,
IMHO, both proposals are too Qt/KDE specific to be integrated into
cmake this way. Maybe cmake could provide a more generic approach
like allowing you to run whatever dependency scanner at some stage in
the build process.
-Nico
On Saturday, June 4, 2011, Alexander Neundorf neund...@kde.org wrote:
Hi,
one feature which all KDE developers are used to and which is also used by
qmake when building Qt is automoc.
This means that you don't have to write
qt4_wrap_cpp(srcs ${filesToBeMoced})
but instead you simply do
kde4_add_executable(hello ${srcs})
and everything including moc is handled automatically.
This is done so that in your foo.cpp file you include the moc-file e.g. at the
end:
---
Foo::Foo()
:QObject()
{
}
...
void Foo::doSomething()
{
}
#include foo.moc
What needs to be done for this is to parse all source files for such include
lines at build time (because such a line may have been inserted without
changing anything in CMakeLists.txt) and if such a line is found, moc has to
be started and the file has to be generated.
Currently this is done by the tool automoc4 which is a separate package.
It consists of a binary automoc4 and a macro
automoc_add_executable().
What this macro basically does is to add for each target foo an additional
target foo_automoc, and make the target foo depend on foo_automoc. So
foo_automoc is always built before foo.
The custom target foo_automoc basically runs the automoc4 executable, which
checks for all source files whether they have changed, and whether they
contain moc-include statements, and if so, it runs moc.
So, we'd like to have that available in cmake.
I see two ways how to do it:
1) keep the mechanism as it is, but integrate the functionality of the automoc
executable into cmake, so that the custom target would do cmake --automoc or
something like this.
This would still need an additional macro, which would then probably be
qt_add_executable().
When doing automoc, the list of source files has to be known, the include
directories and the defines.
This is currently written into a file which is then loaded by automoc4.
When integrating it this way, this would probably stay more or less like this.
2) Integrate it fully into cmake, i.e. add arguments to add_executable() and
add_library(), so I can do
add_executable(foo AUTOMOC ${srcs} )
Advantages of this would be that it doesn't need an extra macro and extra
custom target to be set up, and that the information like the list of files
and include directories is directly available in cmAddExecutable, so it
doesn't have to be written in a separate file which is read later on.
So, we'd really like to have that integrated in cmake.
What do you think ? Which way would you prefer ? I think I'm favouring option
2).
I'll work in the next days on porting current automoc away from using Qt to
plain STL (and kwsys), so that it becomes ready for inclusion. It is also
already BSD licensed.
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
--
Nicolas Desprès
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Making _IMPORT_PREFIX from an installed exports-file available to an including file
Hi,
when installing an export-file cmake has the nice feature to calculate the
CMAKE_INSTALL_PREFIX from the current location:
-8--8--8
# Compute the installation prefix relative to this file.
GET_FILENAME_COMPONENT(_IMPORT_PREFIX ${CMAKE_CURRENT_LIST_FILE} PATH)
GET_FILENAME_COMPONENT(_IMPORT_PREFIX ${_IMPORT_PREFIX} PATH)
GET_FILENAME_COMPONENT(_IMPORT_PREFIX ${_IMPORT_PREFIX} PATH)
GET_FILENAME_COMPONENT(_IMPORT_PREFIX ${_IMPORT_PREFIX} PATH)
GET_FILENAME_COMPONENT(_IMPORT_PREFIX ${_IMPORT_PREFIX} PATH)
# Import target bar for configuration
SET_PROPERTY(TARGET bar APPEND PROPERTY IMPORTED_CONFIGURATIONS NOCONFIG)
...
# Cleanup temporary variables.
SET(_IMPORT_PREFIX)
-8--8--8
I can't do this in cmake-script in a FooConfig.cmake file myself, there I
simply must assume that if I go four levels up that I have reached my install
prefix. This will usually be correct, but it would be nicer if I could reuse
this knowledge which cmake generates into the per-configuration files.
So, I'd like to do from my FooConfig.cmake file something like:
include(${CMAKE_CURRENT_LIST_DIR}/FooExports.cmake)
set(FOO_INCLUDE_DIR ${FooExports_IMPORT_PREFIX}/include )
Related to this, why is this location computed in the configuration-specific
file, and not once in the parent exports-file, which includes all the
export-files for the different configurations ?
The files which will be included are collected with this call:
FILE(GLOB CONFIG_FILES ${_DIR}/BarTargets-*.cmake)
I.e. it is guaranteed that they are all in the same directory as the including
file.
Doesn't that mean that they are also in the same directory relative to their
respective install prefix ?
If so, would it be ok if I move the code for calculating the IMPORT_PREFIX
into the parent exports file ?
Or should I add basically the same code in the generated parent exports-file
?
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Patch for watcom InstallRequiredSystemLibraries
I'd like to know the same. Particularly with respect to whether any documents will need to be signed, and for how much longer patches (that aren't bug fixes) will be accepted to 2.8.5. Thanks, Steven On Sat, Jun 4, 2011 at 1:53 AM, J Decker d3c...@gmail.com wrote: so what is the proper way for someone without repository write access to get patches added? On Tue, Feb 15, 2011 at 3:27 PM, J Decker d3c...@gmail.com wrote: http://public.kitware.com/Bug/view.php?id=11866 ___ 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] VxWorks Cross Compilation Strategy
On Saturday, June 04, 2011 05:09:27 PM Dan Furtney wrote:
Can the pre-link commands be added to the vxworks.cmake with a
ADD_CUSTOM_COMMAND call? I initially tried doing this in the
CMakeLists.txt file via a ADD_CUSTOM_COMMAND(TARGET...) call and a special
LINK command I can't recall.
So you need to do two steps when linking the executable ?
I think (this is not 100% sure) this is not supported.
In the VxWorks.cmake you don't know the names of the targets, so you can't add
custom commands there.
What you can do is to write a macro like
macro(vxworks_add_executable name)
add_executable(${name} ...)
add_custom_command(TARGET ${name} PRE_LINK COMMAND ... )
endmacro()
Then you would have to use this macro in your actual CMakeLists.txt instead of
add_executable() directly.
Alex
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] GenerateExportHeader macrr for CMake?
Hi, I came up with an idea to simplify the creation of export headers for hidden visibility by using configure_file. After implementing it I saw that the idea has come up before :) http://www.mail-archive.com/cmake@cmake.org/msg27058.html Please see the attached proof of concept. Could we get something like GenerateExportHeader.cmake and exportheader.cmake.in into CMake 2.8? Alex tells me I'd have to maintain it, respond to bugs, and keep source compatibility, so I guess I can say I'll do that :). I know there are other special cases for other compilers, but I thought I'd put the implementation of the concrete idea here for discussion at this point. Thanks, Steve. cmake_generate_export.tar.gz Description: application/compressed-tar ___ 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] setting the shell env
On Saturday, June 04, 2011 09:57:44 PM dfurt...@cox.net wrote: Usually we use the vxworks command shell to do command line builds. Windriver supplys many utilites including its own sh.exe. Is there a way to tell CMake to use the windriver sh and/or env setup? Please keep the mailing list on CC, so all can find the information later on, and also all can try to help. Currentlyy I get: C:\DOCUME~1\vaj2850\LOCALS~1\Temp\make51686.sh: c:/WindRiver/utilities-1.0/x86-w in32/bin/sh.exe nmpentium | tclsh C:/WindRiver/vxworks-6.7/host/resource/hutil s/tcl/munch.tcl -c pentium C:/dev/SM3/workbench/CMakeBlah/ctdt.c: command not found Using full paths to the separate executables didn't help. The C:\DOCUME~1\vaj2850\LOCALS~1\Temp\make51686.sh: looks supicious. What kind of environment is this ? So you do this under windows, but with some kind of unix tools ? Is this cygwin or more like mingw ? In general, you should probably run cmake from the shell where you will also build. What kind of command is this above ? Is this generated from a add_custom_command() ? Alex ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] setting the shell env
What kind of environment is this ?
So you do this under windows, but with some kind of unix tools ?
Is this cygwin or more like mingw ?
WindRiver provides the wrenv.exe/.sh (depending on the platform) utility to
help setup the environment for production. It is available for windows and unix
shells. I am running all of the CMake comands from in Windows using such a
shell.
What kind of command is this above ? Is this generated from a
add_custom_command() ?
Yes, it was generated from a custom command. This is what the Workbench version
of vxworks does prior to linking.
ADD_CUSTOM_COMMAND(TARGET Blah PRE_LINK COMMAND nmpentium ${OJBECTS}
${LINK_LIBRARIES} | tclsh
${VX_BASE_DIR}/${VX_VERSION_DIR}/host/resource/hutils/tcl/munch.tcl -c pentium
${CMAKE_BINARY_DIR}/ctdt.c COMMENT Building the cdtc.c file\n)
Here is the full link command I am trying to replicate. LOL, you gotta love
it.
echo building $@;rm -f %OutFile%;nmpentium %Objects% %Libraries% | tclsh
$(WIND_BASE)/host/resource/hutils/tcl/munch.tcl -c pentium
$(OBJ_DIR)/ctdt.c;%ccompilerprefix% $(TOOL_PATH)ccpentium %DebugModeFlags%
$(CC_ARCH_SPEC) -fdollars-in-identifiers -Wall $(ADDED_CFLAGS) %Includes%
$(ADDED_INCLUDES) -DCPU=$(CPU) -DTOOL_FAMILY=$(TOOL_FAMILY) -DTOOL=$(TOOL)
-D_WRS_KERNEL -D_VSB_CONFIG_FILE=\$(VSB_CONFIG_FILE)\ $(DEFINES) -o
$(OBJ_DIR)/ctdt.o -c $(OBJ_DIR)/ctdt.c;%linkerprefix% $(TOOL_PATH)ccpentium -r
-nostdlib -Wl,-X %ToolFlags% -o %OutFile% $(OBJ_DIR)/ctdt.o %Objects%
%Libraries% $(LIBPATH) $(LIBS) $(ADDED_LIBPATH) $(ADDED_LIBS) if [
$(EXPAND_DBG) = 1 ]; then plink $@;fi
I execute cmake using my ToolChain file with the custom command in the
CMakeLists.txt file. When I run make I get:
C:\DOCUME~1\dan\LOCALS~1\Temp\make13924.sh: nmpentium | tclsh C:/WindRiver
/vxworks-6.7/host/resource/hutils/tcl/munch.tcl -c pentium C:/dev/SM3/workbenc
h/CMakeBlah/ctdt.c: command not found
make[2]: *** [Blah] Error 127
make[1]: *** [CMakeFiles/Blah.dir/all] Error 2
make: *** [all] Error 2
It appears that a different shell environment is being picked up for the
execution of make?
Alexander Neundorf a.neundorf-w...@gmx.net wrote:
=
On Saturday, June 04, 2011 09:57:44 PM dfurt...@cox.net wrote:
Usually we use the vxworks command shell to do command line builds.
Windriver supplys many utilites including its own sh.exe. Is there a way
to tell CMake to use the windriver sh and/or env setup?
Please keep the mailing list on CC, so all can find the information later on,
and also all can try to help.
Currentlyy I get:
C:\DOCUME~1\vaj2850\LOCALS~1\Temp\make51686.sh:
c:/WindRiver/utilities-1.0/x86-w in32/bin/sh.exe nmpentium | tclsh
C:/WindRiver/vxworks-6.7/host/resource/hutil s/tcl/munch.tcl -c pentium
C:/dev/SM3/workbench/CMakeBlah/ctdt.c: command not found
Using full paths to the separate executables didn't help. The
C:\DOCUME~1\vaj2850\LOCALS~1\Temp\make51686.sh: looks supicious.
What kind of environment is this ?
So you do this under windows, but with some kind of unix tools ?
Is this cygwin or more like mingw ?
In general, you should probably run cmake from the shell where you will also
build.
What kind of command is this above ? Is this generated from a
add_custom_command() ?
Alex
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, master, updated. v2.8.4-512-ge3aec95
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 e3aec957405f1d344f9da8863b4f860f4662e6dc (commit) from 43824d44f44a29f5f2be9990e5551101b96eb035 (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=e3aec957405f1d344f9da8863b4f860f4662e6dc commit e3aec957405f1d344f9da8863b4f860f4662e6dc Author: KWSys Robot kwro...@kitware.com AuthorDate: Sun Jun 5 00:01:06 2011 -0400 Commit: KWSys Robot kwro...@kitware.com CommitDate: Sun Jun 5 00:11:54 2011 -0400 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index dc8a502..ccfe6e3 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 06) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 04) +SET(KWSYS_DATE_STAMP_DAY 05) --- 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
