Re: [cmake-developers] CPack IFW generator

2014-07-23 Thread Konstantin Podsvirov
Update as of July 23, available!

17.07.2014, 12:04, Konstantin Podsvirov konstan...@podsvirov.pro:
 Hello fans of CMake and Windows!

 I want to present the online installer CMake for 32-bit and 64-bit versions 
 of Windows.

 And immediately the binaries:

 http://ifw.podsvirov.pro/cmake/cmake-master-windows-32bit-online.exe

 http://ifw.podsvirov.pro/cmake/cmake-master-windows-64bit-online.exe

 The installer will install CMake from an online repository and create 
 shortcuts in the start menu.
 The composition of the labels is the same as that of the NSIS installer.

If you have already used these installers then just click Start Menu - CMake 
- Uninstall , then click Update components and click Next ...

Added new features CPack IFW generator.
Now you can specify one or more license file for a group of components or for a 
particular component.

As before the source code is available here:
http://git.podsvirov.pro/?p=cmake/cpackifwgenerator.git;a=summary

HTML version of the documentation is available here:
http://ifw.podsvirov.pro/cmake/doc/cmake-3.0/html

Note the documentation of the module CPackIFW:
http://ifw.podsvirov.pro/cmake/doc/cmake-3.0/html/module/CPackIFW.html

Download the source code and collect it yourself or use installers for Windows 
or Linux http://ifw.podsvirov.pro/cmake).

If there is a need to create an online installers with the possibility of 
renewal for Linux, then contact me and I will make them.

Encouraged to read and test the code and share their comments.

My purpose here to CPack IFW generator became a part of the project CMake!!!

(Sorry for my English, I use a translator)

Regards,
Konstantin Podsvirov
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


[cmake-developers] [CMake 0015034]: target_link_libraries omits some dependencies

2014-07-23 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=15034 
== 
Reported By:Glenn Coombs
Assigned To:
== 
Project:CMake
Issue ID:   15034
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2014-07-23 04:56 EDT
Last Modified:  2014-07-23 04:56 EDT
== 
Summary:target_link_libraries omits some dependencies
Description: 
The target_link_libraries command fails to add the specified linker option under
some conditions.

Steps to Reproduce: 
Save the example CMakeLists.txt file attached to this ticket and then run these
commands:

mkdir build
cd build
cmake ..
make VERBOSE=yes

The link command generated for my_lib_shared is as follows:

gcc -fPIC -shared -Wl,-soname,libmy_lib_shared.so 
-o libmy_lib_shared.so CMakeFiles/my_lib_shared.dir/my_lib_shared.c.o 
libsome_lib_1.a 
-Wl,-whole-archive libsome_lib_3.a -Wl,-no-whole-archive
libsome_lib_2.a 
-Wl,-whole-archive libsome_lib_4.a
libsome_lib_5.a

which is incorrect.  The lib4 line should include a -no-whole-archive option on
the end.  If you comment line 25 and uncomment line 26 in the CMakeLists.txt
then the correct output is generated:

gcc -fPIC -shared -Wl,-soname,libmy_lib_shared.so -o 
libmy_lib_shared.so CMakeFiles/my_lib_shared.dir/my_lib_shared.c.o
libsome_lib_1.a 
-Wl,-whole-archive libsome_lib_3.a -Wl,-no-whole-archive 
libsome_lib_2.a 
-Wl,-whole-archive libsome_lib_4.a -Wl,-Qy,-no-whole-archive
libsome_lib_5.a

For some reason the -no-whole-archive is omitted unless another option precedes
it.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2014-07-23 04:56 Glenn Coombs   New Issue
2014-07-23 04:56 Glenn Coombs   File Added: CMakeLists.txt
==

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


[cmake-developers] CMake generates Makefiles that don't parallelize as much as they could.

2014-07-23 Thread Nick Overdijk
Hey guys,

With this https://github.com/NickNick/cmake-dependency-waiting code here,
why do b wait for a and c wait for b to be build? The object files could
all be build in parallel right? Not doing it is making my distcc-cluster
less and less useful the more nodes I add. Is there a way to fix or work
around this?

Cheers,
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] LZMA support

2014-07-23 Thread David Cole via cmake-developers
Wow! Fantastic!

Thanks to Daniel, great work on this contribution... This is a ton of
tedious work, but it will be very useful. Thank you *very much*.

Two minor comments -- in the commit at the tip of this topic:

http://public.kitware.com/gitweb?p=stage/cmake.git;a=commitdiff;h=5201fb2e62fb06609b02c83278da6546561a9e9f

I think the extensions should be alphabetized, and they should also
include 7z so folks can use the typically smaller 7z files with
ExternalProject as well.

Would you like me to amend and update the topic? Or would you mind
doing the minor edit for that?

BTW, I just submitted an Experimental dashboard for this topic using
ninja and the VS2012 compiler on Windows 8.1, and it was all green:
http://open.cdash.org/buildSummary.php?buildid=3420600


Thanks,
David C.

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could.

2014-07-23 Thread Brad King
On 07/23/2014 08:00 AM, Nick Overdijk wrote:
 With this https://github.com/NickNick/cmake-dependency-waiting code here, why 
 do b wait for a and c wait for b to be build? The object files could all be 
 build in parallel right? Not doing it is making my distcc-cluster less and 
 less useful the more nodes I add. Is there a way to fix or work around
 this?

See here:

 http://www.cmake.org/Bug/view.php?id=14726#c35021
 http://www.cmake.org/Bug/view.php?id=14726#c35023

-Brad

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could.

2014-07-23 Thread Nick Overdijk
Thanks for the quick reply, but what if c needs b and b needs a? Adding
INTERFACE will then break the build of course, right, since b isn't
really linked to a... Or am I mistaken?


On Wed, Jul 23, 2014 at 2:36 PM, Brad King brad.k...@kitware.com wrote:

 On 07/23/2014 08:00 AM, Nick Overdijk wrote:
  With this https://github.com/NickNick/cmake-dependency-waiting code
 here, why do b wait for a and c wait for b to be build? The object files
 could all be build in parallel right? Not doing it is making my
 distcc-cluster less and less useful the more nodes I add. Is there a way to
 fix or work around
  this?

 See here:

  http://www.cmake.org/Bug/view.php?id=14726#c35021
  http://www.cmake.org/Bug/view.php?id=14726#c35023

 -Brad


-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could.

2014-07-23 Thread Nick Overdijk
Oh wait, since a is in the interface of b, b will always be accompanied by
a, even though it's not a dependency. Is that how it works?


On Wed, Jul 23, 2014 at 2:58 PM, Nick Overdijk n...@astrant.net wrote:

 Thanks for the quick reply, but what if c needs b and b needs a? Adding
 INTERFACE will then break the build of course, right, since b isn't
 really linked to a... Or am I mistaken?


 On Wed, Jul 23, 2014 at 2:36 PM, Brad King brad.k...@kitware.com wrote:

 On 07/23/2014 08:00 AM, Nick Overdijk wrote:
  With this https://github.com/NickNick/cmake-dependency-waiting code
 here, why do b wait for a and c wait for b to be build? The object files
 could all be build in parallel right? Not doing it is making my
 distcc-cluster less and less useful the more nodes I add. Is there a way to
 fix or work around
  this?

 See here:

  http://www.cmake.org/Bug/view.php?id=14726#c35021
  http://www.cmake.org/Bug/view.php?id=14726#c35023

 -Brad



-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could.

2014-07-23 Thread Brad King
On 07/23/2014 09:07 AM, Nick Overdijk wrote:
 Oh wait, since a is in the interface of b, b will always be
 accompanied by a, even though it's not a dependency.
 Is that how it works? 

Yes.  If B is a static library then it does not really link so
its dependencies are only ever used transitively when something
else links to B.  If B really links as a shared library though
then see the following.

If target B links to target A then CMake will not compile objects
in B until A is done.  As explained in my previous link this is
because we allow A to contain custom commands that generate
headers used by B.  The VS and Xcode IDE build systems offer only
this granularity since they organize compilation and linking rules
of a single target together.  The Makefile generator was designed
this way too.  Only the Ninja generator has a chance of increasing
parallelism if the extra ordering dependencies were dropped.  We've
thought about how to do extra analysis to determine when there is
no such custom command to drop them but have not implemented anything
yet.

You might be able to use OBJECT libraries to increase parallelism
for all generators and with no changes to CMake:

 set(CMAKE_POSITION_INDEPENDENT_CODE ON)
 add_library(Aobjs OBJECT a1.c a2.c)
 add_library(Bobjs OBJECT b1.c b2.c)
 add_library(Cobjs OBJECT c1.c c2.c)
 set(dummy_c dummy.c) # needed for VS 6 and Xcode
 add_library(A SHARED $TARGET_OBJECTS:Aobjs ${dummy_c})
 add_library(B SHARED $TARGET_OBJECTS:Bobjs ${dummy_c})
 add_library(C SHARED $TARGET_OBJECTS:Cobjs ${dummy_c})
 target_link_libraries(B PUBLIC A)
 target_link_libraries(C PUBLIC B)

This way the object compilations will be completely independent
of one another and of the linking and ordering dependencies.

-Brad

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could.

2014-07-23 Thread Nick Overdijk
Crystal clear. Another layer of indirection eh? I'll see if I can work with
that... Thanks for the explanation.


On Wed, Jul 23, 2014 at 3:14 PM, Brad King brad.k...@kitware.com wrote:

 On 07/23/2014 09:07 AM, Nick Overdijk wrote:
  Oh wait, since a is in the interface of b, b will always be
  accompanied by a, even though it's not a dependency.
  Is that how it works?

 Yes.  If B is a static library then it does not really link so
 its dependencies are only ever used transitively when something
 else links to B.  If B really links as a shared library though
 then see the following.

 If target B links to target A then CMake will not compile objects
 in B until A is done.  As explained in my previous link this is
 because we allow A to contain custom commands that generate
 headers used by B.  The VS and Xcode IDE build systems offer only
 this granularity since they organize compilation and linking rules
 of a single target together.  The Makefile generator was designed
 this way too.  Only the Ninja generator has a chance of increasing
 parallelism if the extra ordering dependencies were dropped.  We've
 thought about how to do extra analysis to determine when there is
 no such custom command to drop them but have not implemented anything
 yet.

 You might be able to use OBJECT libraries to increase parallelism
 for all generators and with no changes to CMake:

  set(CMAKE_POSITION_INDEPENDENT_CODE ON)
  add_library(Aobjs OBJECT a1.c a2.c)
  add_library(Bobjs OBJECT b1.c b2.c)
  add_library(Cobjs OBJECT c1.c c2.c)
  set(dummy_c dummy.c) # needed for VS 6 and Xcode
  add_library(A SHARED $TARGET_OBJECTS:Aobjs ${dummy_c})
  add_library(B SHARED $TARGET_OBJECTS:Bobjs ${dummy_c})
  add_library(C SHARED $TARGET_OBJECTS:Cobjs ${dummy_c})
  target_link_libraries(B PUBLIC A)
  target_link_libraries(C PUBLIC B)

 This way the object compilations will be completely independent
 of one another and of the linking and ordering dependencies.

 -Brad


-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] LZMA support

2014-07-23 Thread Brad King
On 07/23/2014 08:16 AM, David Cole wrote:
 Thanks to Daniel, great work on this contribution... This is a ton of
 tedious work, but it will be very useful. Thank you *very much*.

+1

I've merged the topic to 'next' for testing, but without the CPack
or ExternalProject pieces.  Likely some more portability fixes
will be required after testing on the dashboard.  Once that is clean
I will add the other changes again on top of the revised topic.

 Two minor comments -- in the commit at the tip of this topic:

For reference, that change is to ExternalProject with hunks like:

-  if(filename MATCHES (\\.|=)(bz2|tar\\.gz|tgz|zip)$)
+  if(filename MATCHES (\\.|=)(xz|bz2|tar\\.gz|tgz|zip)$)

 I think the extensions should be alphabetized, and they should also
 include 7z so folks can use the typically smaller 7z files with
 ExternalProject as well.

Thanks.  Actually I think adding xz is incorrect anyway.  We
support compressed tarballs, not arbitrary compressed files.
Therefore the list should be

  7z|bz2|tar\\.gz|tar\\.xz|tgz|txz|zip

correct?

-Brad

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] LZMA support

2014-07-23 Thread Rolf Eike Beer

Am 23.07.2014 16:43, schrieb Brad King:

On 07/23/2014 08:16 AM, David Cole wrote:

Thanks to Daniel, great work on this contribution... This is a ton of
tedious work, but it will be very useful. Thank you *very much*.


+1

I've merged the topic to 'next' for testing, but without the CPack
or ExternalProject pieces.  Likely some more portability fixes
will be required after testing on the dashboard.  Once that is clean
I will add the other changes again on top of the revised topic.


Two minor comments -- in the commit at the tip of this topic:


For reference, that change is to ExternalProject with hunks like:

-  if(filename MATCHES (\\.|=)(bz2|tar\\.gz|tgz|zip)$)
+  if(filename MATCHES (\\.|=)(xz|bz2|tar\\.gz|tgz|zip)$)


I think the extensions should be alphabetized, and they should also
include 7z so folks can use the typically smaller 7z files with
ExternalProject as well.


Thanks.  Actually I think adding xz is incorrect anyway.  We
support compressed tarballs, not arbitrary compressed files.
Therefore the list should be

  7z|bz2|tar\\.gz|tar\\.xz|tgz|txz|zip

correct?


Well, then it should be tar.bz2, too. And since this is a regex anyway:

  7z|tar\\.bz2|tar\\.[gx]z|t[xg]z|zip

Eike
--

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] LZMA support

2014-07-23 Thread Nils Gladitz

On 23.07.2014 16:43, Brad King wrote:

Therefore the list should be

   7z|bz2|tar\\.gz|tar\\.xz|tgz|txz|zip

correct?



bz2 - tar\\.bz2 as well while you are at it(?)

Nils
--

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] LZMA support

2014-07-23 Thread David Cole via cmake-developers

Thanks.  Actually I think adding xz is incorrect anyway.  We
support compressed tarballs, not arbitrary compressed files.
Therefore the list should be

  7z|bz2|tar\\.gz|tar\\.xz|tgz|txz|zip

correct?


Well, then it should be tar.bz2, too. And since this is a regex 

anyway:


   7z|tar\\.bz2|tar\\.[gx]z|t[xg]z|zip


Yes, correct.

I still like the original list all the extensions separately and 
explicitly technique rather than 'simplifying' the regex -- because 
the first one is an easier to parse as a human being regex. Also, 
it's more greppable if somebody is looking for .gz or .xz or tgz or 
txz.



D

--

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


[cmake-developers] [CMake 0015035]: Build time file copy_if_different

2014-07-23 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=15035 
== 
Reported By:Daniele E. Domenichelli
Assigned To:
== 
Project:CMake
Issue ID:   15035
Category:   CMake
Reproducibility:have not tried
Severity:   feature
Priority:   normal
Status: new
== 
Date Submitted: 2014-07-23 13:54 EDT
Last Modified:  2014-07-23 13:54 EDT
== 
Summary:Build time file copy_if_different
Description: 
As a follow up to this thread[1], we agreed that in order to create a project
that other project can use both from the install and build tree, in some cases
it is a good idea to replicate the installation tree or part of it inside the
build directory, so that the relative paths are the same when the package is
used from the build tree or from the installation.

[1]http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10492

file(COPY) copies the file is copied at CMake time, not a build time, and cmake
is not triggered when the original file is modified, and therefore the copy is
not performed at build time if the file is modified and the just runs make (or
build for visual studio and other IDEs). Also file(COPY) does not have an
option to copy the file only if the file(s) is(are) different and could trigger
an unnecessary rebuild.

execute_process(COMMAND ${CMAKE_COMMAND} -E copy_if_different) does not
trigger unnecessary builds, but it is still in the configure phase

configure_file(COPYONLY) still copies the file in the configure phase, but it
will trigger a cmake run if the original file was modified. Nonetheless it has a
few disadvantages:
 * It's less discoverable than file(COPY)
 * It can copy just one file at the time, therefore it is not easy to reproduce
an install tree
 * It triggers a cmake run, that will slow down the build
 * The files to configure might be the product of some build step and therefore
not available during the configure step.

At the moment (as far as I know) the only way to do it is to use
add_custom_command to execute some external CMake script that runs
${CMAKE_COMMAND} -E copy_if_different, but this require a lot of work to
handle the file level and target level dependencies correctly.


It would be very useful to be able to copy files at build time only if
different, without triggering a cmake run, and with a syntax similar to the
install command.


I suggest to implement one of the following ideas:

* Have an option for the install(FILES/PROGRAMS/DIRECTORY) command that
reproduces the install tree in the binary directory, but at build time, and only
if the destination file is missing or is different from the source.

* Add some modes to the export() command, for example
export(FILES/PROGRAMS/DIRECTORY), with the same signature of
install(FILES/PROGRAMS/DIRECTORY), and that replicates the behaviour of this
command but at build time and in in the similar way as export(EXPORT) replicates
the behaviour of install(EXPORT)

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2014-07-23 13:54 Daniele E. DomenichelliNew Issue   

==

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree

2014-07-23 Thread Brad King
On 07/22/2014 07:44 AM, Stephen Kelly wrote:
 Daniele E. Domenichelli wrote:
 By the way, is there a reason why file(COPY) does not have an option to
 copy the file only if the file(s) is(are) different.
 
 configure_file(COPY_ONLY) does that. file(COPY_IF_DIFFERENT) would just do 
 the same thing but would be more discoverable and might be a good idea.

Our file(INSTALL) command used by scripts for make install at one
time did do a copy-if-different but for incremental re-installations
it spent a very long time comparing content.  It was decided instead
to make the re-copy decision based only on the file timestamp comparison.
This makes it very fast.  The file(COPY) command is just a binding to
file(INSTALL) that does not print status messages and has slightly
different defaults.

The file(COPY) command already has many keyword options, so a new
COPY_IF_DIFFERENT to request the time-consuming comparison could be
added.

 Since you were asking if CMake misses some important feature, I believe
 that a very useful feature to have would be to be able to have an option
 for the install(FILES/PROGRAMS/DIRECTORY) command that reproduces the
 install tree in the binary directory
 
 Yes, seems like something worth investigating.

I don't think we need to have a build tree, install-in-build-tree, and
install-tree all managed by a single build tree.  Things like
INSTALL_RPATH do not make sense when there are two possible install
locations.  An install-in-build-tree directory is not easily defined
in multi-config generators.

If you want to test installation then set CMAKE_INSTALL_PREFIX to
$build/prefix or something and use the normal make install target.
Some projects also arrange their layout within the build tree to look
like the install tree by setting CMAKE_RUNTIME_OUTPUT_DIRECTORY[_CONFIG]
and related variables appropriately.

Returning to CMakePackageConfigHelpers, I work on several projects
that provide one pkgConfig.cmake file in the build tree and one
in the install tree.  They are generated by hand.  I do not use
CMakePackageConfigHelpers.  IMO it is good for getting projects
started without having to learn all the details.  For mature projects
that want to do fancy things like supporting applications from the
build tree, manual generation of the package configuration files
becomes worthwhile.

-Brad

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] CPack IFW generator

2014-07-23 Thread Konstantin Podsvirov
CPack IFW generator built an online installer itself on Linux!

23.07.2014, 12:39, Konstantin Podsvirov konstan...@podsvirov.pro:
 Update as of July 23, available!

The installer for 64-bit versions of Linux are available here:
http://ifw.podsvirov.pro/cmake/cmake-master-linux-64bit-online.run

Encouraged to test and write your own reviews.

As before, I will try to build updates once a week.

Regards,
Konstantin Podsvirov
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] CPack IFW generator

2014-07-23 Thread Brad King
On 07/17/2014 03:33 AM, Konstantin Podsvirov wrote:
 Now I fixed it. Should work.

Thanks for this contribution!  I finally made time to look over
the changes and integrate them.  Overall, very nice work.

I squashed your history down to a single commit, fixed newlines,
fixed indentation, fixed long lines, and made couple minor
portability tweaks.  The new draft commit is:

 CPack: Add an IFW generator for Qt Framework Installer
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a9006316

You can compare it to your last commit (3c506bd2) with:

 git diff 3c506bd2 a9006316 -w --color-words=.

to see that there are almost no non-whitespace changes.  I also
added a slightly larger portability change:

 CPackIFW: Replace use of strftime with cmTimestamp
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a943d41d

but I'm not set up to test it.  Please fetch from our repo to try
out these versions to make sure I didn't break anything.

These draft commits are now in 'next' for upstream testing.

Thanks!
-Brad

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [CMake] How to get a list of all the static libraries that a target will link against ?

2014-07-23 Thread Glenn Coombs
I think I have found a way to work round this.  Instead of trying to get a
list of all the static libraries that a target will link against I will
modify the various libraries so that they add their library dependencies
like this:

target_link_libraries(mtx_wrapper PUBLIC

$$STREQUAL:$TARGET_PROPERTY:TYPE,SHARED_LIBRARY:-Wl,-whole-archive
${MTXSIM_LIBRARIES}

$$STREQUAL:$TARGET_PROPERTY:TYPE,SHARED_LIBRARY:-Wl,-no-whole-archive
$$STREQUAL:$CXX_COMPILER_ID,GNU:dl
$$STREQUAL:$CXX_COMPILER_ID,Clang:dl

This should mean that all the dependent libraries get wrapped inside
-whole-archive/-no-whole-archive pairs when the target being linked is a
shared library.  And if the target being linked is an executable then the
-whole-archive/-no-whole-archive options should automatically be omitted.
Initial tests indicate that this approach will work but I have encountered
a bug which slightly complicates the issue:

http://www.cmake.org/Bug/view.php?id=15034

Essentially, the -no-whole-archive option sometimes gets omitted unless
prefixed by some other command.

--
Glenn



On 21 July 2014 19:24, Angeliki Chrysochou angeliki.chrysoc...@gmail.com
wrote:

 Well try it and see if it works. If you set this variable in a specific
 CMakeLists file, it will affect the specific add_library (or
 add_executable) that is in that CMakeLists file. With this way you can
 control which libraries/executables will be linked with these flags, and
 this is the level of control you have.

 Cheers!
 Angeliki



 On Mon, Jul 21, 2014 at 7:05 PM, Glenn Coombs glenn.coo...@gmail.com
 wrote:

 The problem is that I need to add both -whole-archive and
 -no-whole-archive options.  And I need to control exactly where they occur
 so that only my libraries occur inside the whole archive section.  I'd be
 happy to be proven wrong but I don't think setting CMAKE_EXE_LINKER_FLAGS
 will give me that level of control.

 --
 Glenn


 On 21 July 2014 09:57, Angeliki Chrysochou angeliki.chrysoc...@gmail.com
  wrote:

 Hi Glenn,

 Adding linker flags exactly in target_link_libraries is not a very good
 practice in my opinion. To add specific linker flags to an executable, you
 can use the variable CMAKE_EXE_LINKER_FLAGS, which you can edit before
 calling add_executable. You could set this variable accordingly in your
 static and dynamic CMakeLists.txt to include the flags you wish in the
 following way:

 set(CMAKE_EXE_LINKER_FLAGS -whole-archive)

 If you set this variable to include more custom linker flags which you
 want to preserve across libraries, then you should set it in the following
 way to preserve its old value:

 set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} -whole-archive)

 If you want to edit linker flags for a shared library or a module target
 you can use these cmake variables (set them before add_library):

 CMAKE_SHARED_LINKER_FLAGS
 CMAKE_MODULE_LINKER_FLAGS

 Be aware that variables have CMakeLists.txt file scope, so if you set
 different values in one CMakeLists.txt then they might get overwritten or
 appended (depending on the way you edit the variable).

 All the best,
 Angeliki





 On Sat, Jul 19, 2014 at 2:39 PM, Glenn Coombs glenn.coo...@gmail.com
 wrote:

 Don't all shout at once :-)  I'm guessing there are no easy solutions
 then...

 --
 Glenn


 On 28 June 2014 14:33, Glenn Coombs glenn.coo...@gmail.com wrote:

 I have a project which compiles and links into both a stand alone
 executable and a dynamic shared library.  The library and the executable
 link against the same project libraries but have different object files
 containing their entry points: main.o for the executable and dll_main.o 
 for
 the library.  My project heirarchy looks like this (simplified a bit for
 brevity):

 CMakeLists.txt
 mtx_source/CMakeLists.txt
 mtx_wrapper/CMakeLists.txt
 testbench/CMakeLists.txt

 The top level CMakeLists.txt calls add_subdirectory on the various
 project specific library folders which each build a static library.  The
 testbench folder is the one that builds both the executable and the 
 dynamic
 library.  When building the dynamic library I need to use the linker
 options -whole-archive and -no-whole-archive to force my static project
 libraries to be included into the dynamic library. The problem is how to
 insert the -whole-archive and -no-whole-archive options so that they 
 select
 the correct set of libraries.  Currently in the testbench CMakeLists.txt
 file I have these lines:

 set(libs
 VLC
 mvea
 ${SYSTEMC_SUPPORT_LIBRARIES}
 ${DEVIFSLAVE_LIBRARIES}
 ${SYSTEMC_LIBRARIES}
 ${SIM_UTILS_LIBRARIES}
 ${HWDEBUG_LIBRARIES}
 )

 if (NOT STUB_OUT_MTX)
 list(APPEND libs mtx_wrapper)
 endif()

 set(libs_dll ${libs} transif_slave)

 if (UNIX)
 list(INSERT libs_dll 0 -Wl,-whole-archive)
 list(APPEND libs_dll   -Wl,-no-whole-archive)
 endif()

 add_library ( csim_dll SHARED ${sources_dll} ${headers_dll} )
 add_executable( testbench   

Re: [CMake] About the FindCUDA.cmake module ande Separate Compilation

2014-07-23 Thread James Bigler
The CUDA_NVCC_FLAGS variable is a list not a string.  You also have to turn
CUDA_SEPARABLE_COMPILATION on.

Try this

list(APPEND CUDA_NVCC_FLAGS -gencode arch=compute_30,code=sm_30 -rdc=true)
set( CUDA_SEPARABLE_COMPILATION ON)


On Thu, Jul 17, 2014 at 8:07 AM, Notargiacomo Thibault gnthiba...@gmail.com
 wrote:

 Dear All

 I am a user of cmake build system and its differents modules, that
 were very helpful in the past.

 But I met some specific issues with the FindCUDA.cmake module, for
 about a year now. Especially about the Separate Compilation feature,
 that never worked for me, I  previously had to bypass the problem by
 rewriting some code in the same file, but today I am stuck and I have
 to get this feature working.

 What are my files ?
 I have
 ===
 a.cu:
 __constant__ Buffer float[1024];
 __global__ void kernelA( float a )
 {
  Buffer[0] = a;
 }
 ===
 b.cu.h
 extern __constant__ Buffer float[1024];
 ===
 b.cu
 __global__ void kernelB( float b )
 {
  Buffer[0] += b;
 }
 ===

 It is obvious with this configuration, that I have to link b.cu with
 a.cu, in order to get the same memory area shared across them. This
 simple feature seems to be only available if a separate compilation
 configuration build is used, in order to avoid redefinition error, and
 also compiler needs relocatable device code to be setted, this latter
 I don't really understand why.


 What specific feature of the CMake Module I am using ?
 Here are the main macros I am using:

 ===
 list(APPEND CUDA_NVCC_FLAGS  -gencode arch=compute_30,code=sm_30
 -rdc=true )
 set( CUDA_SEPARABLE_COMPILATION )
 cuda_add_executable(${OUTPUT_NAME} ${sources} ${headers})
 ==


 The error I get:
 If I discard the -rdc=true nvcc option for relocatable code, the
 code compiles, and links fine, but at runtime the code does not work
 as expected, ie the value inside the buffer is not shared across
 differents kernel a and b.

 If all options stated before are setted, the code compiles fine, but
 at link step I get tons of link errors that looks like:
  undefined reference to `__cudaRegisterLinkedBinary[...]'

 The problem doesn't seem that hard to solve, as seperate compilation
 is extensively explained in the cuda documentation :

 http://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index.html#using-separate-compilation-in-cuda
 But I still got problems trying to get the separate things to work
 with FindCUDA.cmake.

 Thank you in advance for any help.
 --

 Powered by www.kitware.com

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

 Kitware offers various services to support the CMake community. For more
 information on each offering, please visit:

 CMake Support: http://cmake.org/cmake/help/support.html
 CMake Consulting: http://cmake.org/cmake/help/consulting.html
 CMake Training Courses: http://cmake.org/cmake/help/training.html

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

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/mailman/listinfo/cmake

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Controlling the targets in an export set

2014-07-23 Thread Adar Dembo
I have a project that generates a shared library foo. As part of the build,
the bar1, bar2, and bar3 static archives are created, and eventually, foo
is linked against all of them. Thus, the project's sole deliverable is
libfoo.so; all the necessary symbols from the bar1..bar3 archives are found
within libfoo.so.

If I try to export foo using install(TARGETS foo EXPORT foo ...) and
install(EXPORT foo ...), cmake complains that target foo requires targets
bar1, bar2, and bar3, which are not in the export set. I have to add
install(TARGETS bar1 EXPORT foo ...) for bar1..bar3 if I want this to
succeed. However, this also means that I'm exporting my static archives,
which as I wrote earlier aren't necessary.

How can I exercise finer-grained control over foo's export set? How can I
build an export set containing foo but excluding bar1, bar2, and bar3?
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[Cmake-commits] CMake branch, master, updated. v3.0.0-1476-gea3e544

2014-07-23 Thread Brad King
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  ea3e544098232edcaddf11c5fee5819256c92936 (commit)
   via  f7d62cac79f856c9c7b634ed7f5d2f6030b7ba76 (commit)
  from  a263cab6c22ecfdd18ed592b9efb2d8a8c505852 (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=ea3e544098232edcaddf11c5fee5819256c92936
commit ea3e544098232edcaddf11c5fee5819256c92936
Merge: a263cab f7d62ca
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Jul 23 09:44:32 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jul 23 09:44:32 2014 -0400

Merge topic 'fix_sanitizer_test_to_work_with_sanitizer'

f7d62cac Fix leak and address sanitizer tests to be able to run with real 
tools.


---

Summary of changes:
 Tests/CTestTestMemcheck/CMakeLists.txt |4 ++--
 Tests/CTestTestMemcheck/testAddressSanitizer.cmake |4 
 Tests/CTestTestMemcheck/testLeakSanitizer.cmake|4 
 3 files changed, 10 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits


[Cmake-commits] CMake branch, master, updated. v3.0.0-1478-g91d2151

2014-07-23 Thread Brad King
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  91d21518ae652089dd94a3c9d09e5e800ab0dd6b (commit)
   via  f5c0efdbe4d67a6f262dd670923674b003af1726 (commit)
  from  ea3e544098232edcaddf11c5fee5819256c92936 (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=91d21518ae652089dd94a3c9d09e5e800ab0dd6b
commit 91d21518ae652089dd94a3c9d09e5e800ab0dd6b
Merge: ea3e544 f5c0efd
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Jul 23 09:44:34 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jul 23 09:44:34 2014 -0400

Merge topic 'refactor-generator-startup'

f5c0efdb cmGlobalGenerator: Create a non-virtual 'DoGenerate' method


---

Summary of changes:
 Source/cmGlobalGenerator.cxx |7 ++-
 Source/cmGlobalGenerator.h   |4 +++-
 Source/cmGlobalNinjaGenerator.h  |6 +++---
 Source/cmGlobalVisualStudio10Generator.h |4 ++--
 Source/cmGlobalVisualStudio6Generator.h  |8 +---
 Source/cmGlobalVisualStudio7Generator.h  |8 +---
 Source/cmGlobalVisualStudio8Generator.h  |2 +-
 Source/cmGlobalVisualStudioGenerator.h   |7 ++-
 Source/cmGlobalXCodeGenerator.h  |9 ++---
 Source/cmake.cxx |2 +-
 10 files changed, 22 insertions(+), 35 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits


[Cmake-commits] CMake branch, master, updated. v3.0.0-1474-ga263cab

2014-07-23 Thread Brad King
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  a263cab6c22ecfdd18ed592b9efb2d8a8c505852 (commit)
   via  fb95f820e06eb1933a7d3b71bc46eed4d5d25ee6 (commit)
  from  3e3ab2adb4a70352a41b469788a2885b20a86fef (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=a263cab6c22ecfdd18ed592b9efb2d8a8c505852
commit a263cab6c22ecfdd18ed592b9efb2d8a8c505852
Merge: 3e3ab2a fb95f82
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Jul 23 09:44:29 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jul 23 09:44:29 2014 -0400

Merge topic 'fix-complex-test-policies'

fb95f820 Tests: Set policies in 'complex' tests


---

Summary of changes:
 Tests/Complex/CMakeLists.txt  |   15 +++
 Tests/ComplexOneConfig/CMakeLists.txt |   15 +++
 2 files changed, 30 insertions(+)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits


[Cmake-commits] CMake branch, master, updated. v3.0.0-1483-gfe4e6ed

2014-07-23 Thread Brad King
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  fe4e6ed991b936e147536832bbf7190f05887814 (commit)
   via  848fab9575271f41c9632086011af4c4560702e3 (commit)
   via  85cea8a7af77cd482f4d3c7ec15f68bc5adeb0ba (commit)
   via  e7ee892b391992e0e8198917b8ef5cce76da2fd1 (commit)
   via  9f92a78be21a7f126f1776d481cc4bd2acdf4a1b (commit)
  from  91d21518ae652089dd94a3c9d09e5e800ab0dd6b (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=fe4e6ed991b936e147536832bbf7190f05887814
commit fe4e6ed991b936e147536832bbf7190f05887814
Merge: 91d2151 848fab9
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Jul 23 09:44:35 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jul 23 09:44:35 2014 -0400

Merge topic 'refactor-makerule-path-conversion'

848fab95 cmGlobalVisualStudio7Generator: Remove unused variable
85cea8a7 cmDepends: Refactor object file path conversion
e7ee892b cmLocalGenerator: Fix AddBuildTargetRule object file path 
conversion
9f92a78b cmLocalGenerator: Rename 'MAKEFILE' to 'MAKERULE'


---

Summary of changes:
 Source/cmDepends.cxx|7 +-
 Source/cmDependsC.cxx   |   12 ++---
 Source/cmDependsFortran.cxx |   35 +++
 Source/cmGlobalUnixMakefileGenerator3.cxx   |2 +-
 Source/cmGlobalVisualStudio7Generator.cxx   |1 -
 Source/cmLocalGenerator.cxx |4 +--
 Source/cmLocalGenerator.h   |2 +-
 Source/cmLocalUnixMakefileGenerator3.cxx|4 +--
 Source/cmMakefileTargetGenerator.cxx|6 ++---
 Source/cmMakefileUtilityTargetGenerator.cxx |2 +-
 10 files changed, 40 insertions(+), 35 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits


[Cmake-commits] CMake branch, next, updated. v3.0.0-4449-g1b15ba0

2014-07-23 Thread Brad King
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  1b15ba06c301bffb0a1c8ea0bb38618ba7f07f45 (commit)
   via  fe4e6ed991b936e147536832bbf7190f05887814 (commit)
   via  91d21518ae652089dd94a3c9d09e5e800ab0dd6b (commit)
   via  ea3e544098232edcaddf11c5fee5819256c92936 (commit)
   via  a263cab6c22ecfdd18ed592b9efb2d8a8c505852 (commit)
   via  3e3ab2adb4a70352a41b469788a2885b20a86fef (commit)
  from  eb4594dca202769dc583ea12579fef626295a572 (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=1b15ba06c301bffb0a1c8ea0bb38618ba7f07f45
commit 1b15ba06c301bffb0a1c8ea0bb38618ba7f07f45
Merge: eb4594d fe4e6ed
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Jul 23 09:46:15 2014 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Wed Jul 23 09:46:15 2014 -0400

Merge branch 'master' into next


---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits


[Cmake-commits] CMake branch, next, updated. v3.0.0-4461-g0bf9d58

2014-07-23 Thread Bill Hoffman
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  0bf9d5879e628db98995563428cd3089f4bede3b (commit)
   via  57a2df224a4bcf4463937d5e121f917d450c144f (commit)
  from  c8bae9bacafb95d99f9ebfacf8fdfedbbaf56760 (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=0bf9d5879e628db98995563428cd3089f4bede3b
commit 0bf9d5879e628db98995563428cd3089f4bede3b
Merge: c8bae9b 57a2df2
Author: Bill Hoffman bill.hoff...@kitware.com
AuthorDate: Wed Jul 23 11:14:20 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jul 23 11:14:20 2014 -0400

Merge topic 'fix_tar_leaks' into next

57a2df22 Fix memory leaks in extract tar.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=57a2df224a4bcf4463937d5e121f917d450c144f
commit 57a2df224a4bcf4463937d5e121f917d450c144f
Author: Bill Hoffman bill.hoff...@kitware.com
AuthorDate: Wed Jul 23 11:13:17 2014 -0400
Commit: Bill Hoffman bill.hoff...@kitware.com
CommitDate: Wed Jul 23 11:13:17 2014 -0400

Fix memory leaks in extract tar.

diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx
index 444e143..fbb4416 100644
--- a/Source/cmSystemTools.cxx
+++ b/Source/cmSystemTools.cxx
@@ -1701,6 +1701,8 @@ bool extract_tar(const char* outFileName, bool verbose,
 {
 cmSystemTools::Error(Problem with archive_read_open_file(): ,
  archive_error_string(a));
+archive_write_free(ext);
+archive_read_close(a);
 return false;
 }
   for (;;)
@@ -1776,6 +1778,7 @@ bool extract_tar(const char* outFileName, bool verbose,
 }
   }
 }
+  archive_write_free(ext);
   archive_read_close(a);
   archive_read_finish(a);
   return r == ARCHIVE_EOF || r == ARCHIVE_OK;

---

Summary of changes:
 Source/cmSystemTools.cxx |3 +++
 1 file changed, 3 insertions(+)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits


[Cmake-commits] CMake branch, next, updated. v3.0.0-4463-g4d5b9ce

2014-07-23 Thread Brad King
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  4d5b9cedbbfc835801712143fd4b87da729dbdea (commit)
   via  3119297312e0a512c71863621a137871f405788a (commit)
  from  0bf9d5879e628db98995563428cd3089f4bede3b (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=4d5b9cedbbfc835801712143fd4b87da729dbdea
commit 4d5b9cedbbfc835801712143fd4b87da729dbdea
Merge: 0bf9d58 3119297
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Jul 23 11:40:01 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jul 23 11:40:01 2014 -0400

Merge topic 'add-liblzma' into next

31192973 liblzma: Port to VS 7.0


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3119297312e0a512c71863621a137871f405788a
commit 3119297312e0a512c71863621a137871f405788a
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Jul 23 11:38:18 2014 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Wed Jul 23 11:38:18 2014 -0400

liblzma: Port to VS 7.0

Use the same UINT64_C suffix as that for VS 6.

diff --git a/Utilities/cmliblzma/common/sysdefs.h 
b/Utilities/cmliblzma/common/sysdefs.h
index 81e10c1..7481e3d 100644
--- a/Utilities/cmliblzma/common/sysdefs.h
+++ b/Utilities/cmliblzma/common/sysdefs.h
@@ -51,7 +51,7 @@
 #endif
 
 
-#if defined(_MSC_VER)  (_MSC_VER = 1200)
+#if defined(_MSC_VER)  (_MSC_VER  1310)
 #  define UINT64_C(n) n ## ui64
 #endif
 

---

Summary of changes:
 Utilities/cmliblzma/common/sysdefs.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits


[Cmake-commits] CMake branch, next, updated. v3.0.0-4465-g07a2eb5

2014-07-23 Thread Brad King
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  07a2eb5d4fb3988bf61c71bad00636464a736e4a (commit)
   via  96e815146d6b185fcd0d024ee03ced59e6789341 (commit)
  from  4d5b9cedbbfc835801712143fd4b87da729dbdea (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=07a2eb5d4fb3988bf61c71bad00636464a736e4a
commit 07a2eb5d4fb3988bf61c71bad00636464a736e4a
Merge: 4d5b9ce 96e8151
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Jul 23 11:55:01 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jul 23 11:55:01 2014 -0400

Merge topic 'add-liblzma' into next

96e81514 liblzma: Disable warnings to avoid changing 3rd party code


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=96e815146d6b185fcd0d024ee03ced59e6789341
commit 96e815146d6b185fcd0d024ee03ced59e6789341
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Jul 23 11:55:25 2014 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Wed Jul 23 11:55:25 2014 -0400

liblzma: Disable warnings to avoid changing 3rd party code

diff --git a/Utilities/cmliblzma/CMakeLists.txt 
b/Utilities/cmliblzma/CMakeLists.txt
index 85efa8c..fc50dbe 100644
--- a/Utilities/cmliblzma/CMakeLists.txt
+++ b/Utilities/cmliblzma/CMakeLists.txt
@@ -190,6 +190,16 @@ INCLUDE_DIRECTORIES(
   ${CMLIBLZMA_BINARY_DIR}
   )
 
+# Disable warnings to avoid changing 3rd party code.
+IF(${CMAKE_C_COMPILER_ID} MATCHES
+^(GNU|Clang|AppleClang|XL|VisualAge|SunPro|MIPSpro|HP|Intel)$)
+  SET(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -w)
+ELSEIF(${CMAKE_C_COMPILER_ID} MATCHES ^(PathScale)$)
+  SET(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -woffall)
+ELSEIF(BORLAND)
+  SET(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -w-)
+ENDIF()
+
 ADD_LIBRARY(cmliblzma ${LZMA_SRCS})
 
 INSTALL(FILES COPYING DESTINATION ${CMAKE_DOC_DIR}/cmliblzma)

---

Summary of changes:
 Utilities/cmliblzma/CMakeLists.txt |   10 ++
 1 file changed, 10 insertions(+)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits


[Cmake-commits] CMake branch, next, updated. v3.0.0-4471-g0afd1b4

2014-07-23 Thread Brad King
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  0afd1b43e011968426a0d8f892f03039334d997c (commit)
   via  09164c637b02f964152453bdbe1b1591c39c1f7c (commit)
   via  29a0642ba78392ab20037e677d28eae2eea23de7 (commit)
   via  8fa087ab38c41e76e502f438eff42d412962108f (commit)
   via  1c209ac165cd2c25c632cdd238a9948c1651f907 (commit)
   via  91c933546d1eebb6a637f403824d63177c86c11e (commit)
  from  07a2eb5d4fb3988bf61c71bad00636464a736e4a (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=0afd1b43e011968426a0d8f892f03039334d997c
commit 0afd1b43e011968426a0d8f892f03039334d997c
Merge: 07a2eb5 09164c6
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Jul 23 16:23:13 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jul 23 16:23:13 2014 -0400

Merge topic 'vs-escaping' into next

09164c63 VS: Encode more content correctly in vcxproj files (#15031)
29a0642b VS: Encode mapped flag values in XML project files (#15031)
8fa087ab cmVisualStudioGeneratorOptions: Simplify XML escaping API
1c209ac1 cmIDEOption: Store mapped flag values as a vectorstring
91c93354 cmVisualStudio10TargetGenerator: Remove dupilcate line


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=09164c637b02f964152453bdbe1b1591c39c1f7c
commit 09164c637b02f964152453bdbe1b1591c39c1f7c
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Jul 23 15:03:28 2014 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Wed Jul 23 15:14:47 2014 -0400

VS: Encode more content correctly in vcxproj files (#15031)

In cmVisualStudio10TargetGenerator, add missing cmVS10EscapeXML
calls around paths to source and object files, custom command
dependencies and outputs, and platform name/version values.

diff --git a/Source/cmVisualStudio10TargetGenerator.cxx 
b/Source/cmVisualStudio10TargetGenerator.cxx
index 2429e59..5674317 100644
--- a/Source/cmVisualStudio10TargetGenerator.cxx
+++ b/Source/cmVisualStudio10TargetGenerator.cxx
@@ -343,19 +343,20 @@ void cmVisualStudio10TargetGenerator::Generate()
 }
 
   this-WriteString(Platform, 2);
-  (*this-BuildFileStream)  this-Platform  /Platform\n;
+  (*this-BuildFileStream)  cmVS10EscapeXML(this-Platform)
+/Platform\n;
   const char* projLabel = this-Target-GetProperty(PROJECT_LABEL);
   if(!projLabel)
 {
 projLabel = this-Name.c_str();
 }
   this-WriteString(ProjectName, 2);
-  (*this-BuildFileStream)  projLabel  /ProjectName\n;
+  (*this-BuildFileStream)  cmVS10EscapeXML(projLabel)  /ProjectName\n;
   if(const char* targetFrameworkVersion = this-Target-GetProperty(
VS_DOTNET_TARGET_FRAMEWORK_VERSION))
 {
 this-WriteString(TargetFrameworkVersion, 2);
-(*this-BuildFileStream)  targetFrameworkVersion
+(*this-BuildFileStream)  cmVS10EscapeXML(targetFrameworkVersion)
   /TargetFrameworkVersion\n;
 }
   this-WriteString(/PropertyGroup\n, 1);
@@ -507,7 +508,8 @@ void 
cmVisualStudio10TargetGenerator::WriteProjectConfigurations()
 this-WriteString(Configuration, 3);
 (*this-BuildFileStream )   *i  /Configuration\n;
 this-WriteString(Platform, 3);
-(*this-BuildFileStream)  this-Platform  /Platform\n;
+(*this-BuildFileStream)  cmVS10EscapeXML(this-Platform)
+  /Platform\n;
 this-WriteString(/ProjectConfiguration\n, 2);
 }
   this-WriteString(/ItemGroup\n, 1);
@@ -700,7 +702,7 @@ 
cmVisualStudio10TargetGenerator::WriteCustomRule(cmSourceFile const* source,
 (*this-BuildFileStream )  script  /Command\n;
 this-WritePlatformConfigTag(AdditionalInputs, i-c_str(), 3);
 
-(*this-BuildFileStream )  source-GetFullPath();
+(*this-BuildFileStream )  cmVS10EscapeXML(source-GetFullPath());
 for(std::vectorstd::string::const_iterator d =
   ccg.GetDepends().begin();
 d != ccg.GetDepends().end();
@@ -710,7 +712,7 @@ 
cmVisualStudio10TargetGenerator::WriteCustomRule(cmSourceFile const* source,
   if(this-LocalGenerator-GetRealDependency(d-c_str(), i-c_str(), dep))
 {
 this-ConvertToWindowsSlash(dep);
-(*this-BuildFileStream )  ;  dep;
+(*this-BuildFileStream )  ;  cmVS10EscapeXML(dep);
 }
   }
 (*this-BuildFileStream )  ;%(AdditionalInputs)/AdditionalInputs\n;
@@ -723,7 +725,7 @@ 
cmVisualStudio10TargetGenerator::WriteCustomRule(cmSourceFile const* source,
   {
   std::string out = *o;
   this-ConvertToWindowsSlash(out);
-  (*this-BuildFileStream )  sep  out;
+  

[Cmake-commits] CMake branch, next, updated. v3.0.0-4474-g8f819c4

2014-07-23 Thread Brad King
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  8f819c4968965da6864b39446885e6ee51eb5d54 (commit)
   via  a943d41d5c275fc30803909defd2d9adb557b518 (commit)
   via  a9006316315bd4f0d091bdb2a5cb2f8de3e08e63 (commit)
  from  0afd1b43e011968426a0d8f892f03039334d997c (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=8f819c4968965da6864b39446885e6ee51eb5d54
commit 8f819c4968965da6864b39446885e6ee51eb5d54
Merge: 0afd1b4 a943d41
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Jul 23 16:35:08 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jul 23 16:35:08 2014 -0400

Merge topic 'cpack-ifw-generator' into next

a943d41d CPackIFW: Replace use of strftime with cmTimestamp
a9006316 CPack: Add an IFW generator for Qt Framework Installer


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a943d41d5c275fc30803909defd2d9adb557b518
commit a943d41d5c275fc30803909defd2d9adb557b518
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Jul 23 16:31:15 2014 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Wed Jul 23 16:35:51 2014 -0400

CPackIFW: Replace use of strftime with cmTimestamp

The latter is more portable.

diff --git a/Source/CPack/cmCPackIFWGenerator.cxx 
b/Source/CPack/cmCPackIFWGenerator.cxx
index a4f33b4..51c0f2e 100644
--- a/Source/CPack/cmCPackIFWGenerator.cxx
+++ b/Source/CPack/cmCPackIFWGenerator.cxx
@@ -19,6 +19,7 @@
 #include cmGeneratedFileStream.h
 #include cmCPackLog.h
 #include cmCPackComponentGroup.h
+#include cmTimestamp.h
 
 #include cmsys/SystemTools.hxx
 #include cmsys/Glob.hxx
@@ -809,16 +810,8 @@ int cmCPackIFWGenerator::IfwCreatePackageFile()
 //--
 std::string cmCPackIFWGenerator::IfwCreateCurrentDate()
 {
-  time_t rawtime;
-  struct tm * timeinfo;
-  char buffer[80];
-
-  time (rawtime);
-  timeinfo = localtime(rawtime);
-
-  strftime(buffer, 80, %Y-%m-%d, timeinfo);
-
-  return buffer;
+  cmTimestamp timestamp;
+  return timestamp.CurrentTime(%Y-%m-%d, false);
 }
 
 //--

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a9006316315bd4f0d091bdb2a5cb2f8de3e08e63
commit a9006316315bd4f0d091bdb2a5cb2f8de3e08e63
Author: Konstantin Podsvirov konstan...@podsvirov.pro
AuthorDate: Wed Jul 23 11:01:59 2014 +0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Wed Jul 23 16:35:45 2014 -0400

CPack: Add an IFW generator for Qt Framework Installer

Add support for packaging with the Qt Framework Installer tools:

 http://qt-project.org/doc/qtinstallerframework/index.html

Reviewed-by: Nils Gladitz nilsglad...@gmail.com

diff --git a/CMakeCPack.cmake b/CMakeCPack.cmake
index fb55bfc..9d56779 100644
--- a/CMakeCPack.cmake
+++ b/CMakeCPack.cmake
@@ -59,11 +59,39 @@ if(EXISTS ${CMAKE_ROOT}/Modules/CPack.cmake)
   if(${CPACK_SYSTEM_NAME} MATCHES Windows)
 if(CMAKE_CL_64)
   set(CPACK_SYSTEM_NAME win64-x64)
+  set(CPACK_IFW_TARGET_DIRECTORY @RootDir@/Program 
Files/${CMAKE_PROJECT_NAME})
 else()
   set(CPACK_SYSTEM_NAME win32-x86)
 endif()
   endif()
 
+  # default component for IFW
+  set(_CPACK_IFW_COMPONENT_NAME ${CMAKE_INSTALL_DEFAULT_COMPONENT_NAME})
+  string(TOUPPER ${_CPACK_IFW_COMPONENT_NAME} _CPACK_IFW_COMPONENT_UNAME)
+
+  if(${CMAKE_SYSTEM_NAME} MATCHES Windows)
+if(BUILD_QtDialog)
+  set(_CPACK_IFW_SHORTCUT_OPTIONAL 
${_CPACK_IFW_SHORTCUT_OPTIONAL}component.addOperation(\CreateShortcut\, 
\@TargetDir@/bin/cmake-gui.exe\, \@StartMenuDir@/CMake 
(cmake-gui).lnk\);\n)
+endif()
+if(SPHINX_HTML)
+  set(_CPACK_IFW_SHORTCUT_OPTIONAL 
${_CPACK_IFW_SHORTCUT_OPTIONAL}component.addOperation(\CreateShortcut\, 
\@TargetDir@/doc/cmake-${CMake_VERSION_MAJOR}.${CMake_VERSION_MINOR}/html/index.html\,
 \@StartMenuDir@/CMake Documentation.lnk\);\n)
+endif()
+configure_file(${CMake_SOURCE_DIR}/Source/QtIFW/installscript.qs.in
+  ${CMake_BINARY_DIR}/installscript.qs @ONLY
+)
+install(FILES ${CMake_SOURCE_DIR}/Source/QtIFW/cmake.org.html
+  DESTINATION .
+)
+set(_CPACK_IFW_COMPONENT_SCRIPT 
set(CPACK_IFW_COMPONENT_${_CPACK_IFW_COMPONENT_UNAME}_SCRIPT 
\${CMake_BINARY_DIR}/installscript.qs\))
+  endif()
+
+  if(${CMAKE_SYSTEM_NAME} MATCHES Linux)
+set(CPACK_IFW_TARGET_DIRECTORY @HomeDir@/${CMAKE_PROJECT_NAME})
+set(CPACK_IFW_ADMIN_TARGET_DIRECTORY 
@ApplicationsDir@/${CMAKE_PROJECT_NAME})
+  endif()
+
+  set(_CPACK_IFW_PACKAGE_VERSION 

[Cmake-commits] CMake branch, master, updated. v3.0.0-1484-gafe21fc

2014-07-23 Thread Kitware 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  afe21fc3c43af0c031a77b3b48041d35f248f481 (commit)
  from  fe4e6ed991b936e147536832bbf7190f05887814 (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=afe21fc3c43af0c031a77b3b48041d35f248f481
commit afe21fc3c43af0c031a77b3b48041d35f248f481
Author: Kitware Robot kwro...@kitware.com
AuthorDate: Thu Jul 24 00:01:10 2014 -0400
Commit: Kitware Robot kwro...@kitware.com
CommitDate: Thu Jul 24 00:01:10 2014 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 2d17cbe..054cf09 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 0)
-set(CMake_VERSION_PATCH 20140723)
+set(CMake_VERSION_PATCH 20140724)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits