Re: [CMake] CMake 2.8.7-rc2 ready for testing!

2011-12-30 Thread Eric Noulard
2011/12/27 Alan W. Irwin ir...@beluga.phys.uvic.ca:

Hi Alan,

 The issue is that if I set CMAKE_LIBRARY_PATH to find a special
 version of lapack/blas, only the lapack part of that is honored.  For
 example, if I set

 export CMAKE_LIBRARY_PATH=/home/software/lapack/install_double/lib

Did you tried with CMAKE_FIND_ROOT_PATH instead?

cmake -DCMAKE_FIND_ROOT_PATH:PATH=/home/software/lapack/install_double
/path/to/source

in fact I wasn't even aware of the CMAKE_LIBRARY_PATH nor friends
like CMAKE_PREFIX_PATH and the like.

How do they interact with CMAKE_FIND_ROOT_PATH ?


-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.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


Re: [CMake] CMake 2.8.7-rc2 ready for testing!

2011-12-30 Thread Eric Noulard
2011/12/30 David Cole david.c...@kitware.com:

 There is no conservative course here. There is a choice of whether to make
 CMake 2.8.7 behave the same as 2.8.6 or the same as 2.8.5.

 For this to be a showstopper it would have had to be reported before we
 tagged 2.8.6 -- since it is now already in 2.8.6, it should simply be
 considered a bug that we will try to address as soon as possible and get it
 merged into master in time for the following release.

 It would also be nice if this were more than simply a back-and-forth
 discussion between you and I. I would sure appreciate more input from other
 LAPACK and BLAS clients.

May be no-so-simple Find modules
(FindLAPACK is 307 lines long and FindBLAS is 624 lines long)
deserve a dedicated dashboard.
The interested user could setup a submission to this dashboard for their
favorite software build such that testing would be more systematic.

May be it could be done with some ctest scripts that would submit
the update/configure/build/test of the interested project to
this FindLAPACK dashboard?

 I will take this as a personal lesson not to
 schedule a release of any kind the week in between Christmas and New Year's.

I thought you did chose that windows to avoid too much complaint,
for this one :-]

Just kidding.
No one raised the hand when you announced the release date, so
I bet we all have responsability in this.

 If we stick to our schedule throughout the coming year, I'll make sure that
 the December release of CMake next year is well *before* Christmas.

Good decision though.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.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


Re: [CMake] on find_package and building dependencies

2011-12-30 Thread Eric Noulard
2011/12/30 Ryan Lewis m...@ryanlewis.net:
 Hi, yes, this is all that I can't figure out if I type the define
 without a type, it fails, but I can't figure out this variables type.
 I tried STRING and FILEPATH and even BOOL.

This is a PATH, so;
cmake -DCMAKE_FIND_ROOT_PATH:PATH=/path/to/custom/install

but I think this is not the problem, since it works for me here
(even if I do not provide the PATH type) so to answer your previous
question:

 Is there a way to hand this to cmake on the command line (i.e. an
 ExternalProject_Add), when I test on the command line with: cmake
 -DCMAKE_FIND_ROOT_PATH=... it gives me the warning that it is ignoring
 my define.

CMake warns you because some values in cache (the one found in CMakeCache.txt)
make cmake not using the value provided on the command line.

Most probably because
ZLIB_INCLUDE_DIR and ZLIB_LIBRARY have been cached so that
CMAKE_FIND_ROOT_PATH is not used because there is no need to.

Basically this also means your build tree wasn't clean when you did run CMake.
Please:
  1) clean-up your source tree from any CMake generated file leftover
  2) use out-of-source build
  http://www.cmake.org/Wiki/CMake_FAQ#Out-of-source_build_trees

Then try again.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.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


Re: [CMake] How to install then test?

2011-12-30 Thread Nicolas Desprès
On Thu, Dec 29, 2011 at 8:01 PM, Denis Scherbakov
denis_scherba...@yahoo.com wrote:
 Dear All!

 Maybe someone can help me: I have a project, we compile binaries and then
 using various INSTALL directives finish the job by copying files where they
 belong: to bin, man, libexec, etc. The point is, we need to run 
 executables after they got installed into this tree, because otherwise
 they won't find all auxiliary files during runtime.

 So I am really missing the point here: how to install files (to a temporary
 directory, for example) and then run various tests? Maybe someone has ideas...


Are you asking for distcheck feature like with the autotools?

Cheers,

-- 
Nicolas Desprès
--

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] FTP client in CMake?

2011-12-30 Thread Robert Dailey
Thanks David. Apparently I was looking in the wrong place, I assumed it
would be a cmake option :)

Happy New Year!!

-
Robert Dailey


On Thu, Dec 29, 2011 at 5:11 PM, David Cole david.c...@kitware.com wrote:

 file(DOWNLOAD ...) works with ftp: urls.

 For example, the following script works for me (with CMake 2.8.6):

   get_filename_component(dir ${CMAKE_CURRENT_LIST_FILE} PATH)

   file(DOWNLOAD
 ftp://ftp.cs.brown.edu/pub/benchmark.ps.Z;
 ${dir}/benchmark.ps.Z
 )

 I found a small file on the first server mentioned by google when
 searching for public anonymous ftp server


 HTH,
 David


 On Thu, Dec 29, 2011 at 6:01 PM, Robert Dailey rcdai...@gmail.com wrote:

 I don't think I've seen a way to use CMake to download files from an FTP
 server. For certain third party libraries, I'd like to store them on an FTP
 server and use CMAKE_COMMAND to invoke CMake.exe from within a cmake script
 to download the files from that FTP server.

 Is it possible to add this functionality? Could anyone recommend a
 workaround?

 -
 Robert Dailey

 --

 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] Interrupt problems in cmake-gui

2011-12-30 Thread Robert Dailey
I have a foreach/while loop that checks if files exist. The files it is
checking are on a Windows network share. So, each check takes a while.
Sometimes after I click Configure in cmake-gui.exe, I want to click
Stop during this check. However, the stop does not seem to interrupt the
loop. I know this because let's say the whole loop takes 20 seconds to
complete. If I let the loop run without clicking stop, it takes 20 seconds.
If I click stop at about 10 seconds, then 10 seconds later it stops. In
other words, clicking stop does not take affect until 20 seconds have
passed anyway. So it obviously isn't stopping it. My loops basically look
like this:

while()
   foreach()
  if( EXISTS )
  endif()
   endforeach()
endwhile()

If I am checking 20 files, each check takes about 1 second to equal a total
time of 20 seconds. So, at most, after clicking stop, there should be a 1
second wait time.

Can anyone verify that while/foreach loops can or cannot be interrupted by
cmake-gui?

-
Robert Dailey
--

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] Interrupt problems in cmake-gui

2011-12-30 Thread Robert Dailey
I found the problem in code and currently have a fix. However, the code
change requires some thread synchronization. Does anyone know if there is a
reader/writer lock object in the CMake source code?

-
Robert Dailey


On Fri, Dec 30, 2011 at 9:58 AM, Robert Dailey rcdai...@gmail.com wrote:

 I have a foreach/while loop that checks if files exist. The files it is
 checking are on a Windows network share. So, each check takes a while.
 Sometimes after I click Configure in cmake-gui.exe, I want to click
 Stop during this check. However, the stop does not seem to interrupt the
 loop. I know this because let's say the whole loop takes 20 seconds to
 complete. If I let the loop run without clicking stop, it takes 20 seconds.
 If I click stop at about 10 seconds, then 10 seconds later it stops. In
 other words, clicking stop does not take affect until 20 seconds have
 passed anyway. So it obviously isn't stopping it. My loops basically look
 like this:

 while()
foreach()
   if( EXISTS )
   endif()
endforeach()
 endwhile()

 If I am checking 20 files, each check takes about 1 second to equal a
 total time of 20 seconds. So, at most, after clicking stop, there should be
 a 1 second wait time.

 Can anyone verify that while/foreach loops can or cannot be interrupted by
 cmake-gui?

 -
 Robert Dailey

--

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] CMake 2.8.7-rc2 ready for testing!

2011-12-30 Thread Alan W. Irwin

On 2011-12-30 11:22+0100 Eric Noulard wrote:


2011/12/30 David Cole david.c...@kitware.com:


There is no conservative course here. There is a choice of whether to make
CMake 2.8.7 behave the same as 2.8.6 or the same as 2.8.5.

For this to be a showstopper it would have had to be reported before we
tagged 2.8.6 -- since it is now already in 2.8.6, it should simply be
considered a bug that we will try to address as soon as possible and get it
merged into master in time for the following release.

It would also be nice if this were more than simply a back-and-forth
discussion between you and I. I would sure appreciate more input from other
LAPACK and BLAS clients.


May be no-so-simple Find modules
(FindLAPACK is 307 lines long and FindBLAS is 624 lines long)
deserve a dedicated dashboard.
The interested user could setup a submission to this dashboard for their
favorite software build such that testing would be more systematic.

May be it could be done with some ctest scripts that would submit
the update/configure/build/test of the interested project to
this FindLAPACK dashboard?


There is no doubt that the lapack/blas software ecosystem is one of
the most complicated out there with many different platforms so it is
easy to make a mistake in the associated find modules that slips
through because not all of those platforms are currently tested
systematically for a given CMake release cycle.

So I think Eric's idea of a dedicated dashboard to help organize
systematic platform testing for the lapack/blas find modules is an
excellent one.

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
__
--

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] Interrupt problems in cmake-gui

2011-12-30 Thread clin...@elemtech.com
There isn't a lock.

Synchronization is done by threads having event loops and calling Qt slots in a 
queued fashion (like posting messages to the other event queue).

I imagine you just need to add another place where the interrupt is checked and 
gracefully return (which should take you back to the event loop).

Clint

- Reply message -
From: Robert Dailey rcdai...@gmail.com
Date: Fri, Dec 30, 2011 10:07 am
Subject: [CMake] Interrupt problems in cmake-gui
To: CMake ML cmake@cmake.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

Re: [CMake] CMake 2.8.7-rc2 ready for testing!

2011-12-30 Thread Alan W. Irwin

On 2011-12-30 11:06+0100 Eric Noulard wrote:


2011/12/27 Alan W. Irwin ir...@beluga.phys.uvic.ca:

Hi Alan,


The issue is that if I set CMAKE_LIBRARY_PATH to find a special
version of lapack/blas, only the lapack part of that is honored.  For
example, if I set

export CMAKE_LIBRARY_PATH=/home/software/lapack/install_double/lib


Did you tried with CMAKE_FIND_ROOT_PATH instead?

cmake -DCMAKE_FIND_ROOT_PATH:PATH=/home/software/lapack/install_double
/path/to/source

in fact I wasn't even aware of the CMAKE_LIBRARY_PATH nor friends
like CMAKE_PREFIX_PATH and the like.


Hmm. I had never heard of CMAKE_FIND_ROOT_PATH until now, but it
certainly wasn't around when I learned all about CMAKE_LIBRARY_PATH
and CMAKE_INCLUDE_PATH years ago.  I guess the problem is I have too
long a history with CMake, and I haven't been paying enough attention to
the more recently developed features.  :-)

I tried the cmake option
-DCMAKE_FIND_ROOT_PATH:PATH=/home/software/lapack/install_double
with both cmake-2.8.5 and cmake-2.8.7-rc2 and got the same results
as before: the desired consistent lapack/blas libraries for 2.8.5, i.e.
-- LAPACK_LIBRARIES =
/home/software/lapack/install_double/lib/liblapack.a;/home/software/lapack/install_double/lib/libblas.a

and an inconsistent mixture of libraries for rc2, i.e.,

-- LAPACK_LIBRARIES =
/home/software/lapack/install_double/lib/liblapack.a;/usr/lib/libf77blas.so.3gf;/usr/lib/libatlas.so.3gf

The above two results were obtained both with and without CMAKE_LIBRARY_PATH
set.

So it appears this is a second regression for the rc2 version of the
lapack/blas find modules compared to 2.8.5; CMAKE_FIND_ROOT_PATH is
partially ignored.

I hope Dave draws the right conclusion here.  :-)

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
__
--

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] CMake 2.8.7-rc2 ready for testing!

2011-12-30 Thread Alan W. Irwin

I have investigated further, and I now think Dave is right with his
desire to go ahead with the release of the rc2 versions of the
lapack/blas find modules.  (Sorry, Dave, for this flip-flop at the
last minute, but such deeper investigations take time.)

What appears to be going on is that in 2.8.5 the usual mechanisms to
choose libraries (CMAKE_LIBRARY_PATH, CMAKE_FIND_ROOT_PATH) work
correctly because they trump (according to my tests) the vendor choice
(which defaults to ALL).
So even though my system has both an atlas and generic version of blas 
installed, that
is ignored for 2.8.5 and the generic blas version is used instead from
the location designated by CMAKE_LIBRARY_PATH or CMAKE_FIND_ROOT_PATH).

But in 2.8.7-rc2, the vendor choice trumps CMAKE_LIBRARY_PATH and
CMAKE_FIND_ROOT_PATH.  So given a choice between the generic version
of blas in CMAKE_LIBRARY_PATH and my system's generic and atlas
versions of blas, rc2 picks the system atlas version.  I guess that is
a reasonable choice because for large matrices atlas is normally
faster than the generic version.  However, for small matrices (such as
in FreeEOS) it is noticeably slower.

So in sum, there has been a fundamental shift in how the lapack/blas
libraries are chosen.  I assume that was a deliberate change in design
so it was probably unfair for me to call it a regression, but a
prominent announcement of this important change would have been
appropriate to avoid misunderstandings.

For my own use case, I have found setting -DBLA_VENDOR:STRING=Generic
and CMAKE_LIBRARY_PATH (or presumably CMAKE_FIND_ROOT_PATH which
I haven't tested for this configuration) gives me

-- LAPACK_LIBRARIES =
/home/software/lapack/install_double/lib/liblapack.a;/home/software/lapack/install_double/lib/libblas.a

i.e., the results I want for FreeEOS both 2.8.5 and 2.8.7-rc2.

That'a slightly more complicated for FreeEOS users (which tend to have
their own built versions of lapack/blas just like I do) than what
worked up to and including CMake-2.8.5.  But that additional
complication is completely acceptable.

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
__
--

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] CMake 2.8.7-rc2 ready for testing!

2011-12-30 Thread David Cole
On Fri, Dec 30, 2011 at 3:25 PM, Alan W. Irwin ir...@beluga.phys.uvic.cawrote:

 I have investigated further, and I now think Dave is right with his
 desire to go ahead with the release of the rc2 versions of the
 lapack/blas find modules.  (Sorry, Dave, for this flip-flop at the
 last minute, but such deeper investigations take time.)

 What appears to be going on is that in 2.8.5 the usual mechanisms to
 choose libraries (CMAKE_LIBRARY_PATH, CMAKE_FIND_ROOT_PATH) work
 correctly because they trump (according to my tests) the vendor choice
 (which defaults to ALL).
 So even though my system has both an atlas and generic version of blas
 installed, that
 is ignored for 2.8.5 and the generic blas version is used instead from
 the location designated by CMAKE_LIBRARY_PATH or CMAKE_FIND_ROOT_PATH).

 But in 2.8.7-rc2, the vendor choice trumps CMAKE_LIBRARY_PATH and
 CMAKE_FIND_ROOT_PATH.  So given a choice between the generic version
 of blas in CMAKE_LIBRARY_PATH and my system's generic and atlas
 versions of blas, rc2 picks the system atlas version.  I guess that is
 a reasonable choice because for large matrices atlas is normally
 faster than the generic version.  However, for small matrices (such as
 in FreeEOS) it is noticeably slower.

 So in sum, there has been a fundamental shift in how the lapack/blas
 libraries are chosen.  I assume that was a deliberate change in design
 so it was probably unfair for me to call it a regression, but a
 prominent announcement of this important change would have been
 appropriate to avoid misunderstandings.

 For my own use case, I have found setting -DBLA_VENDOR:STRING=Generic
 and CMAKE_LIBRARY_PATH (or presumably CMAKE_FIND_ROOT_PATH which
 I haven't tested for this configuration) gives me


 -- LAPACK_LIBRARIES =
 /home/software/lapack/install_**double/lib/liblapack.a;/home/**
 software/lapack/install_**double/lib/libblas.a

 i.e., the results I want for FreeEOS both 2.8.5 and 2.8.7-rc2.

 That'a slightly more complicated for FreeEOS users (which tend to have
 their own built versions of lapack/blas just like I do) than what
 worked up to and including CMake-2.8.5.  But that additional
 complication is completely acceptable.


 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
 __



I don't know about the rest of you here, but I certainly welcome
flip-floppers when they flip over to my side of a debate. :-)

2.8.7 is imminent!
--

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] CMake 2.8.7 available for download

2011-12-30 Thread David Cole
On behalf of myself, Ken, Bill, Brad, Alex, Zach, Ben and the rest of
the CMake team from all around the world, we are pleased to announce
that CMake 2.8.7 is now available for download at:

  http://www.cmake.org/files/v2.8/?C=M;O=D

It is also available from the usual download links found on the CMake web site:

  http://www.cmake.org/cmake/resources/software.html

This email is also available as a blog post:

  http://www.kitware.com/blog/home/post/219

Some of the notable changes in this release are:
- improved Eclipse support
- incremental improvements to the AUTOMOC feature added in the previous release
- more cryptographic hash implementations (SHA1, SHA224, SHA256, SHA384, SHA512)
- file(...) and string(...) command additions for computing hash values
- added LINK_PUBLIC and LINK_PRIVATE options to target_link_libraries command
- new module: DeployQt4
- and, as always, various minor bug fixes

Similar to the previous release, we do not have pre-built binaries for
the SunOS anymore. However, now we have two sets of installers for the
Mac. The Darwin versions are for Mac OSX 10.4 and later, and are
ppc;i386 universal binaries. The Darwin64 versions are for 10.6
and later, and are x86_64;i386 universal binaries.

There was a bit of a network connectivity snag in building the
binaries for the AIX platform today... Because of this, the tarballs
for AIX will not be available until sometime next week.

Following is the complete list of changes in this release. Please try
this version of CMake on your projects and report any issues to the
list or the bug tracker.


Thanks for using CMake! (and Happy New Year!)

-Dave


Changes in CMake 2.8.7 (since 2.8.7-rc2)

None

Changes in CMake 2.8.7-rc2 (since 2.8.7-rc1)

Alex Neundorf (5):
  automoc: default to strict mode, use CMAKE_AUTOMOC_RELAXED_MODE
  automoc: improved warning message in relaxed mode
  Remove trailing whitespace
  Add comment about one more problem of the C depency scanner.
  fix #12262: dependency scanning for ASM files

Bill Hoffman (1):
  Fix the case where cmake --build failed with two project cmds in one file.

Brad King (11):
  KWSys: Correctly handle empty environment variables
  FortranCInterface: Work around mingw32-make trouble with parens
  Xcode: Create separate rerun dependencies for subprojects (#12616)
  Fix Intel Fortran .vfproj files for VS 10
  HP: Drive shared library linking with compiler front end
  Follow all dependencies of shared library private dependencies
  Do not link private dependent shared libraries on OS X  10.4
  Avoid clobbering variable 'OUTPUT' in compiler tests (#12628)
  Fix and simplify Fortran test compiler compatibility check
  CTest: Recognize Intel errors without space before colon (#12627)
  Windows-GNU: Remove extra quotes in GNUtoMS rule variable

David Cole (4):
  Release: Increase timeout for slow-testing cygwin build
  Modules: Use windres as rc compiler base name for
cross-compiles (#12480)
  Tests: Only really run MFC test if we can build MFC apps (#11213)
  FindBoost: Quote possibly empty string argument (#12273)

Eric NOULARD (1):
  CPackRPM fix #0012608 and unoticed related bug

Johan Fänge (1):
  CMake: Fix progress reporting for custom targets (#12441)

Mike McQuaid (2):
  Unset configurations variable when no build type.
  Improve component support and output indentation.

Raphael Kubo da Costa (2):
  Remove the apparently outdated README in Source/QtDialog.
  QtDialog: Set Ctrl+Q as the shortcut for quitting the program.

Tim Gallagher (2):
  FindLAPACK: Correct CMAKE_FIND_LIBRARY_SUFFIXES spelling (#12624)
  FindLAPACK: List thread libs to avoid link errors (#12625)

Valat Sébastien (1):
  CTest: Do not get CDash version without drop site (#12618)

Changes in CMake 2.8.7-rc1 (since 2.8.6)

Aaron Ten Clay (1):
  VS: Add support for three new project properties (#12586)

Alex Neundorf (60):
  fix #12392: handle CMAKE_CXX_COMPILER_ARG1 for Eclipse projects
  fix #12262: use the C dependency scanner also for ASM files
  fix #12465: detect the masm compiler ID (MSVC)
  Silence make on OpenBSD in FindPackageModeTest(#12508)
  Remove trailing whitespace
  Find Ruby on OpenBSD when installed from ports (#12507)
  Eclipse generator: detect Eclipse version
  Detect whether the current Eclipse version supports VirtualFolders
  Eclipse: don't create VirtualFolders if not supported
  Eclipse: better message when Eclipse version could not be determined
  automoc:run moc on the header if the source file contains
include foo.moc
  Add copyright notices
  automoc: always run moc on the cpp file if there is a foo.moc included
  Eclipse: add virtual folder for each target
  Eclipse: move code for 

Re: [CMake] Upcoming What's New in CMake 2.8.7 webinar

2011-12-30 Thread David Cole
On Wed, Dec 21, 2011 at 4:04 PM, Marcus D. Hanwell
marcus.hanw...@kitware.com wrote:
 On Wed, Dec 21, 2011 at 3:50 PM, Alexander Neundorf
 a.neundorf-w...@gmx.net wrote:
 On Wednesday 21 December 2011, David Cole wrote:
 The CMake team is hard at work on the 2.8.7 release - we
 announcedhttp://www.kitware.com/blog/home/post/208 CMake
 2.8.7 rc1 on December 8th, and we expect to release the final version by
 the end of the year. Want to learn more? Then please join us on
 January 4th from
 12:00-12:20 p.m. EST, when I will be presenting a free webinar highlighting
 what’s new in the CMake 2.8.7 release and giving a preview of what’s in the
 pipeline. You'll also get a chance to ask the CMake team any questions you
 may have on this release in particular or CMake in general. You can
 register for this event through
 GoToWebinarhttps://www3.gotomeeting.com/register/152723134
 .
 https://www3.gotomeeting.com/register/152723134
 Please note that you'll need to attend this webinar from a Windows or Mac
 computer - GoToWebinar does not yet support Linux.

 Are there plans for GoToWebinar to support also Linux ?
 It's really a pity that also the other webinars by Kitware exclude Linux :-/

 Agreed, I can't view them on my desktop. I have access to those other
 platforms on secondary machines at least, but it would be great to
 allow viewing of our webinars on the platforms we are targeting. Are
 there any good alternatives you know of Alex?

 Marcus
 --

 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


Katie, from our communications group, contacted the GoToWebinar folks
and got this response:
We do not currently have plans to support Linux OS. I can send a
suggestion to our developers on your behalf, so they can consider it
for future updates.

And then directly from Katie:
I realize it's terribly annoying, but we haven't found a better
webinar-hosting option yet, though we'd be open to suggestions.

So there you have it. No Windows+Mac+Linux solution is known at this
point, at any price, let alone a reasonable price, but we are open to
suggestions if somebody knows of an existing option.


Thx,
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] Interrupt problems in cmake-gui

2011-12-30 Thread Robert Dailey
I don't know much about Qt, but what I do know is the fix involves using a
direct connection. In CMakeSetupDialog::doInterrupt(), I changed the
invokeMethod() command to use Qt::DirectConnection.

However, this solution is not thread safe, hence why I asked about
synchronization. I could implement a multiple-reader/single-writer lock,
but I'd much rather use Boost.Thread, but this would require introducing
the boost library into the cmake build.

The following methods in cmSystemTools need to be made thread-safe (using a
combination of read locks  writer locks). Qt has a reader/writer lock but
I can't use this in cmSystemTools, since it will require cmake.exe to
depend on Qt, which doesn't make much sense.

GetErrorOccuredFlag()
SetFatalErrorOccured()
GetFatalErrorOccured()
ResetErrorOccuredFlag()

I was thinking of turning cmSystemTools into a singleton (you would have a
static instance() method and access members through that) and using
inheritance to implement a thread-safe variant of this class. I could
create thread-safe overrides the above methods and utilize polymorphism to
access the thread safe version in cmake-gui, whereas cmake.exe would not
use it, since by itself it does not need it.

I'd like to introduce boost into CMake for this.

If you can find a better implementation that'd be great, I haven't been
working with the CMake code base as long as you guys have, so you probably
know an easier fix. The main issue is that the blocking functions (such as
while, foreach) do not return control to Qt until after they are done
executing, and the only way to reliably interrupt them is by setting the
fatal error flag. It requires no additional interrupt logic. These are the
findings of my investigation and debugging.

Thanks in advance for your input.

-
Robert Dailey


On Fri, Dec 30, 2011 at 12:53 PM, clin...@elemtech.com clin...@elemtech.com
 wrote:

 There isn't a lock.

 Synchronization is done by threads having event loops and calling Qt slots
 in a queued fashion (like posting messages to the other event queue).

 I imagine you just need to add another place where the interrupt is
 checked and gracefully return (which should take you back to the event
 loop).

 Clint


 - Reply message -
 From: Robert Dailey rcdai...@gmail.com
 Date: Fri, Dec 30, 2011 10:07 am
 Subject: [CMake] Interrupt problems in cmake-gui
 To: CMake ML cmake@cmake.org

 I found the problem in code and currently have a fix. However, the code
 change requires some thread synchronization. Does anyone know if there is a
 reader/writer lock object in the CMake source code?

 -
 Robert Dailey


 On Fri, Dec 30, 2011 at 9:58 AM, Robert Dailey rcdai...@gmail.com wrote:

 I have a foreach/while loop that checks if files exist. The files it is
 checking are on a Windows network share. So, each check takes a while.
 Sometimes after I click Configure in cmake-gui.exe, I want to click
 Stop during this check. However, the stop does not seem to interrupt the
 loop. I know this because let's say the whole loop takes 20 seconds to
 complete. If I let the loop run without clicking stop, it takes 20 seconds.
 If I click stop at about 10 seconds, then 10 seconds later it stops. In
 other words, clicking stop does not take affect until 20 seconds have
 passed anyway. So it obviously isn't stopping it. My loops basically look
 like this:

 while()
foreach()
   if( EXISTS )
   endif()
endforeach()
 endwhile()

 If I am checking 20 files, each check takes about 1 second to equal a
 total time of 20 seconds. So, at most, after clicking stop, there should be
 a 1 second wait time.

 Can anyone verify that while/foreach loops can or cannot be interrupted
 by cmake-gui?

 -
 Robert Dailey



--

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] [EXTERNAL] Re: execute_process appending redirected output

2011-12-30 Thread Michael Hertling
On 12/28/2011 05:39 PM, Belcourt, K. Noel wrote:
 Hi Aaron,
 
 On Dec 27, 2011, at 11:04 PM, Aaron Ten Clay wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 12/27/11 16:16, Belcourt, Kenneth wrote:
 I'm trying to get CMake to execute this command

 INSTALL(CODE
 EXECUTE_PROCESS (COMMAND cat
 \${CMAKE_CURRENT_SOURCE_DIR}/onejar_classpath.txt 
 ${CMAKE_INSTALL_PREFIX}/onejar/boot-manifest.mf\)
 )

 but this doesn't work, here's the error I get when I run the install.

 I've checked that both the source and target files exist and are
 writable. Any ideas on how to get this to work?

 It looks as thought you might be missing some escaped double-quotes.
 
 I've tried quite a few quoting permutations, none work.
 
 INSTALL(CODE
 EXECUTE_PROCESS (COMMAND cat
 \${CMAKE_CURRENT_SOURCE_DIR}/onejar_classpath.txt\ 
 \${CMAKE_INSTALL_PREFIX}/onejar/boot-manifest.mf\)
 )
 
 Unfortunately this doesn't work.

AFAIK, this is because EXECUTE_PROCESS() doesn't fork a shell to run
the COMMANDs, so the redirection operators like  are meaningless.

 It's also worth noting that this is not a cross-platform command.
 
 Yup, we're a unix only shop.

Then use one of the premier *nix tools:

INSTALL(CODE EXECUTE_PROCESS(COMMAND sh -c \cat
\\\${CMAKE_CURRENT_SOURCE_DIR}/onejar_classpath.txt\\\ 
\\\${CMAKE_INSTALL_PREFIX}/onejar/boot-manifest.mf))

Regards,

Michael

 Maybe
 look at file(READ ...) followed by file(APPEND ...)?
 
 Looks promising, I'll check this out.
 
 Thanks for the help Aaron.
 
 -- Noel
--

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] Interrupt problems in cmake-gui

2011-12-30 Thread Bill Hoffman

On 12/30/2011 8:10 PM, Robert Dailey wrote:


I'd like to introduce boost into CMake for this.

No way... :)

-Bill
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] Interrupt problems in cmake-gui

2011-12-30 Thread Clinton Stimpson

Yeah it does look like synchronization is needed to fix this.  The current 
interrupt functionality depends on message output or progress reporting to 
actually process the interrupt on the worker thread, which isn't good enough.

I'm not sure if you've considered this, but it seems simpler to add an 
interrupt callback in cmSystemTools, much like the callbacks work for 
stdout/stderr.  Then cmake-gui could register an interrupt callback and 
coordinate that with the button click.  The synchronization of a simple flag 
can then be handled within cmake-gui using QAtomicInt.

Clint

On Dec 30, 2011, at 6:10 PM, Robert Dailey wrote:

 I don't know much about Qt, but what I do know is the fix involves using a 
 direct connection. In CMakeSetupDialog::doInterrupt(), I changed the 
 invokeMethod() command to use Qt::DirectConnection.
 
 However, this solution is not thread safe, hence why I asked about 
 synchronization. I could implement a multiple-reader/single-writer lock, but 
 I'd much rather use Boost.Thread, but this would require introducing the 
 boost library into the cmake build.
 
 The following methods in cmSystemTools need to be made thread-safe (using a 
 combination of read locks  writer locks). Qt has a reader/writer lock but I 
 can't use this in cmSystemTools, since it will require cmake.exe to depend on 
 Qt, which doesn't make much sense.
 
 GetErrorOccuredFlag()
 SetFatalErrorOccured()
 GetFatalErrorOccured()
 ResetErrorOccuredFlag()
 
 I was thinking of turning cmSystemTools into a singleton (you would have a 
 static instance() method and access members through that) and using 
 inheritance to implement a thread-safe variant of this class. I could create 
 thread-safe overrides the above methods and utilize polymorphism to access 
 the thread safe version in cmake-gui, whereas cmake.exe would not use it, 
 since by itself it does not need it.
 
 I'd like to introduce boost into CMake for this.
 
 If you can find a better implementation that'd be great, I haven't been 
 working with the CMake code base as long as you guys have, so you probably 
 know an easier fix. The main issue is that the blocking functions (such as 
 while, foreach) do not return control to Qt until after they are done 
 executing, and the only way to reliably interrupt them is by setting the 
 fatal error flag. It requires no additional interrupt logic. These are the 
 findings of my investigation and debugging.
 
 Thanks in advance for your input.
 
 -
 Robert Dailey
 
 
 On Fri, Dec 30, 2011 at 12:53 PM, clin...@elemtech.com clin...@elemtech.com 
 wrote:
 There isn't a lock.
 
 Synchronization is done by threads having event loops and calling Qt slots in 
 a queued fashion (like posting messages to the other event queue).
 
 I imagine you just need to add another place where the interrupt is checked 
 and gracefully return (which should take you back to the event loop).
 
 Clint
 
 
 - Reply message -
 From: Robert Dailey rcdai...@gmail.com
 Date: Fri, Dec 30, 2011 10:07 am
 Subject: [CMake] Interrupt problems in cmake-gui
 To: CMake ML cmake@cmake.org
 
 I found the problem in code and currently have a fix. However, the code 
 change requires some thread synchronization. Does anyone know if there is a 
 reader/writer lock object in the CMake source code?
 
 -
 Robert Dailey
 
 
 On Fri, Dec 30, 2011 at 9:58 AM, Robert Dailey rcdai...@gmail.com wrote:
 I have a foreach/while loop that checks if files exist. The files it is 
 checking are on a Windows network share. So, each check takes a while. 
 Sometimes after I click Configure in cmake-gui.exe, I want to click Stop 
 during this check. However, the stop does not seem to interrupt the loop. I 
 know this because let's say the whole loop takes 20 seconds to complete. If I 
 let the loop run without clicking stop, it takes 20 seconds. If I click stop 
 at about 10 seconds, then 10 seconds later it stops. In other words, clicking 
 stop does not take affect until 20 seconds have passed anyway. So it 
 obviously isn't stopping it. My loops basically look like this:
 
 while()
foreach()
   if( EXISTS )
   endif()
endforeach()
 endwhile()
 
 If I am checking 20 files, each check takes about 1 second to equal a total 
 time of 20 seconds. So, at most, after clicking stop, there should be a 1 
 second wait time.
 
 Can anyone verify that while/foreach loops can or cannot be interrupted by 
 cmake-gui?
 
 -
 Robert Dailey
 
 

--

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] [EXTERNAL] Re: execute_process appending redirected output

2011-12-30 Thread Belcourt, K. Noel


On Dec 30, 2011, at 8:05 PM, Michael Hertling wrote:


On 12/28/2011 05:39 PM, Belcourt, K. Noel wrote:

Hi Aaron,

On Dec 27, 2011, at 11:04 PM, Aaron Ten Clay wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/27/11 16:16, Belcourt, Kenneth wrote:

I'm trying to get CMake to execute this command

INSTALL(CODE
EXECUTE_PROCESS (COMMAND cat

\${CMAKE_CURRENT_SOURCE_DIR}/onejar_classpath.txt 
${CMAKE_INSTALL_PREFIX}/onejar/boot-manifest.mf\)

)

but this doesn't work, here's the error I get when I run the  
install.


I've checked that both the source and target files exist and are

writable. Any ideas on how to get this to work?



It looks as thought you might be missing some escaped double-quotes.


I've tried quite a few quoting permutations, none work.


INSTALL(CODE
EXECUTE_PROCESS (COMMAND cat
\${CMAKE_CURRENT_SOURCE_DIR}/onejar_classpath.txt\ 
\${CMAKE_INSTALL_PREFIX}/onejar/boot-manifest.mf\)
)


Unfortunately this doesn't work.


AFAIK, this is because EXECUTE_PROCESS() doesn't fork a shell to run
the COMMANDs, so the redirection operators like  are meaningless.


It's also worth noting that this is not a cross-platform command.


Yup, we're a unix only shop.


Then use one of the premier *nix tools:

INSTALL(CODE EXECUTE_PROCESS(COMMAND sh -c \cat
\\\${CMAKE_CURRENT_SOURCE_DIR}/onejar_classpath.txt\\\ 
\\\${CMAKE_INSTALL_PREFIX}/onejar/boot-manifest.mf))


Eek, that's a lot of quoting.  I found a workaround but thanks for  
this, I may use it if opportunity arises in the future.  Perhaps this:



AFAIK, this is because EXECUTE_PROCESS() doesn't fork a shell to run
the COMMANDs, so the redirection operators like  are meaningless.


could be entered into the documentation somewhere as this is important  
to know.  Thanks for the help Michael.


-- Noel


--

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.6-451-gb1d9295

2011-12-30 Thread David Cole
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  b1d92955af1dbb566137baf0ed883f9aa054faf8 (commit)
   via  7f8f6dbf45aa5250281c7e383e3d32599590564b (commit)
   via  72d27044729f6b6ce2730107c75e99375cd7075a (commit)
   via  a1c9de5635313258272fa1579a4c4d5d779a9788 (commit)
   via  25b159cdbf90fb34cf162bcf4938a15b95b4ea6e (commit)
   via  56b5a72ebd869d32ebb7bf349009e760c9bb3b8f (commit)
  from  add4ad1098a38c719a71fcb6e375fa50ce7be8ae (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
---

Summary of changes:
 CMakeLists.txt   |2 +-
 ChangeLog.manual |  319 ++
 2 files changed, 320 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-2332-g2ccd809

2011-12-30 Thread David Cole
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  2ccd80971863f5c2acc9be6f21f3f60ce1b299ef (commit)
   via  b1d92955af1dbb566137baf0ed883f9aa054faf8 (commit)
   via  7f8f6dbf45aa5250281c7e383e3d32599590564b (commit)
   via  72d27044729f6b6ce2730107c75e99375cd7075a (commit)
   via  add4ad1098a38c719a71fcb6e375fa50ce7be8ae (commit)
   via  15cebeb047d2a8be09a556898f70ed6be2d5fa16 (commit)
   via  38bc4b5d9e4682bfd98dffa10e374c0d6d72e801 (commit)
   via  11385ba56ac890e32e239a52e2ea68e3b2042f7a (commit)
   via  6eb0779dbe0746c47c44374ea3dd4d6472083de6 (commit)
   via  087b8feee4a7a32255cfc529f8526929a788f986 (commit)
   via  4fe0206e923517e7f565cc359ba7c2aed2dd39c2 (commit)
   via  9fc5faceea105fae26bf559e22ae9f55cc12ae90 (commit)
   via  b81ef0533c19a979868040b9bbebd49209297bef (commit)
   via  a1c9de5635313258272fa1579a4c4d5d779a9788 (commit)
   via  25b159cdbf90fb34cf162bcf4938a15b95b4ea6e (commit)
   via  b4c2f40653332dfd1ea6abb81bfa5ab6a22acfe1 (commit)
   via  56b5a72ebd869d32ebb7bf349009e760c9bb3b8f (commit)
  from  1f5d9142fe572d63aaf96391e08e671642c6994c (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=2ccd80971863f5c2acc9be6f21f3f60ce1b299ef
commit 2ccd80971863f5c2acc9be6f21f3f60ce1b299ef
Merge: 1f5d914 b1d9295
Author: David Cole david.c...@kitware.com
AuthorDate: Fri Dec 30 15:26:36 2011 -0500
Commit: David Cole david.c...@kitware.com
CommitDate: Fri Dec 30 15:26:36 2011 -0500

Merge branch 'master' into next


---

Summary of changes:
 CMakeLists.txt|2 +-
 ChangeLog.manual  |  319 +
 Source/kwsys/kwsysDateStamp.cmake |2 +-
 3 files changed, 321 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, master, updated. v2.8.6-452-g3a29d37

2011-12-30 Thread KWSys Robot
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  3a29d37b164d3567b26cbc22763692ae692c16b4 (commit)
  from  b1d92955af1dbb566137baf0ed883f9aa054faf8 (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=3a29d37b164d3567b26cbc22763692ae692c16b4
commit 3a29d37b164d3567b26cbc22763692ae692c16b4
Author: KWSys Robot kwro...@kitware.com
AuthorDate: Sat Dec 31 00:05:04 2011 -0500
Commit: KWSys Robot kwro...@kitware.com
CommitDate: Sat Dec 31 00:05:04 2011 -0500

KWSys Nightly Date Stamp

diff --git a/Source/kwsys/kwsysDateStamp.cmake 
b/Source/kwsys/kwsysDateStamp.cmake
index 2f009e0..eeb97f3 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   30)
+SET(KWSYS_DATE_STAMP_DAY   31)

---

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