Re: [cmake-developers] Preparing for CMake 3.1.0-rc1

[Konstantin Podsvirov]

Hello people!

07.10.2014, 18:43, Brad King brad.k...@kitware.com:
 In order to get the dashboard cleaned up for final merges to
 'master' before the release, please refrain from merging any
 changes other than dashboard fixes and documentation updates
 to 'next'.

 Thanks,
 -Brad

CMake 3.0.20141008-ge5734 Documentation with the latest updates:

Sphinx
http://ifw.podsvirov.pro/cmake/doc/sphinx

Doxygen
http://ifw.podsvirov.pro/cmake/doc/doxygen

Can also upgrade the components in your online installers :-)

All a good day!

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 0015199]: Better error message for export conflicts

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=15199 
== 
Reported By:Nico Schlömer
Assigned To:
== 
Project:CMake
Issue ID:   15199
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2014-10-09 05:11 EDT
Last Modified:  2014-10-09 05:11 EDT
== 
Summary:Better error message for export conflicts
Description: 
If an export target depends on another target, that other target must either be

 * in the same export set, or
 * in exactly one other export set.

If it is not in the same export set and in more than one other export set, CMake
reports
```
CMake Error: install(EXPORT A ...) includes target b which requires target
c that is not in this export set, but 5 times in others.
```
This error message is somewhat misleading; one could think that c must be in
the same export set as b.

Perhaps a less ambiguous wording would be:
```
CMake Error: install(EXPORT A ...) includes target b which requires target
c that is 
  * not in this export set, and
  * in more than one other export set (5).
```
I'm sure we can do even better than that.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2014-10-09 05:11 Nico Schlömer  New 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

[cmake-developers] [CMake 0015200]: Odd quoting issue when mixing single, double and escaped quotes to COMMAND

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=15200 
== 
Reported By:Ray Donnelly
Assigned To:
== 
Project:CMake
Issue ID:   15200
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2014-10-09 08:24 EDT
Last Modified:  2014-10-09 08:24 EDT
== 
Summary:Odd quoting issue when mixing single, double and
escaped quotes to COMMAND
Description: 
Using the following CMakeList.txt:

add_executable (blender blender.c)

set(TARGETDIR_VER C:/Program Files (x86)/Blender/share/blender/2.72)

add_custom_command(
  TARGET blender POST_BUILD MAIN_DEPENDENCY blender
  COMMAND ${CMAKE_COMMAND} -E echo 'now run: \make install\ to copy runtime
files and scripts to ${TARGETDIR_VER}'
)

Using any old blender.c (hello world will do)
And either MSYS Makefiles or MinGW Makefiles generators (actually I suspect
any Makefile generator at all), we get badly quoted strings in
CMakeFiles/blender.dir/build.make:

/C/cmake-3.0.2-win32-x86/bin/cmake.exe -E echo 'now run: make install to copy
runtime files and scripts to C:/Program Files
(x86)/Blender/share/blender/2.72'

It seems that the final ' and  have been swapped, which causes:
/bin/sh: -c: line 0: unexpected EOF while looking for matching `'

Steps to Reproduce: 
unzip quote-problem.7z, and from the MSYS2 shell enter:

/c/cmake-3.0.2-win32-x86/bin/cmake.exe -G'MSYS Makefiles'
make

and observe the error message above.

Additional Information: 
This happens on the officially release 3.0.2 Windows binary and also on MSYS2's
cmake.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2014-10-09 08:24 Ray Donnelly   New Issue
2014-10-09 08:24 Ray Donnelly   File Added: quote-problem.7z
==

-- 

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] fix-OSX-bundle-rpaths-and-Qt5 topic

[Brad King]

Adam,

On 10/08/2014 12:17 PM, Clinton Stimpson wrote:
 Yeah.  I'm curious if changes to BundleUtilities.cmake in fix-OSX-bundle-
 rpaths-and-Qt5 will gracefully handle the BundleUtilities test case with 
 @rpath on OS X 10.5.  Perhaps it'll recognize there is no need to change 
 rpaths.

The BundleUtilities test still fails on OS X 10.5:

 http://open.cdash.org/testDetails.php?test=285651145build=3522021
 -- 6/10: fixing up 
'/.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/testbundleutils1'
 install_name_tool: more than one input file specified 
(/.../Tests/BundleUtilities/testdir1 and -delete_rpath)
 Usage: install_name_tool [-change old new] ... [-id name] input

Clinton's changes in his rpath-osx-10_6 extension topic to yours teach
other uses of -delete_rpath to warn on OS X 10.5 and skip deletion.
I think something similar will be needed here.  Please investigate.

Meanwhile, on my local OS X 10.9 machine I added this patch:

diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake
index eedab44..80e5d3b 100644
--- a/Modules/BundleUtilities.cmake
+++ b/Modules/BundleUtilities.cmake
@@ -755,6 +755,7 @@ function(fixup_bundle_item resolved_embedded_item exepath 
dirs)
   #
   if(changes)
 execute_process(COMMAND install_name_tool ${changes} 
${resolved_embedded_item})
+message(STATUS CHANGE install_name_tool ${changes} 
\${resolved_embedded_item}\)
   endif()
 endfunction()

From the test output I can see that it is trying to delete several
rpath entries that do not exist and therefore do not need deletion.
How is the list chosen for each binary?

-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] fix-OSX-bundle-rpaths-and-Qt5 topic

[clinton]

- Original Message -
 On 10/08/2014 11:05 AM, clin...@elemtech.com wrote:
  I pushed more fixes for this.  Instead of requiring 10.6,
  I took the other path of warning when rpaths need changed
  at install time and skip it.
  This should also fix the CMP0042 test which started failing.
 
 Thanks.  The message is currently:
 
  +  msg  WARNING: Target \  this-Target-GetName()
  + \ has runtime paths which cannot be changed during install.
  
  + To change runtime paths, OS X version 10.6 or newer is
  required.  
  + Therefore, runtime paths will not be changed when
  installing.;
  +  cmSystemTools::Message(msg.str().c_str(), Warning);
 
 Can that be changed to an IssueMessage, possibly on a cmMakefile
 for at least a little context?  Also it should suggest using
 CMAKE_BUILD_WITH_INSTALL_RPATH.
 
  By the way, Brad, your change to require 10.6 for the
  BundleUtilities test is no longer required on the rpath-osx-10_6 topic.
  
 
 I thought it was a missing piece of your original change.
 Since you've reverted that I've now reverted mine so we'll
 see how testing goes.
 
  However, it may still be required for the fix-OSX-bundle-rpaths-and-Qt5
  topic.
 
 I rebased rpath-osx-10_6 on fix-OSX-bundle-rpaths-and-Qt5 to
 make local testing of both together easier.  Please base the
 above-requested fixes on:
 
  OSX: Warn when attempting to change runtime paths on OS X 10.5
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6e58f55
 

Adam,

I was looking at the BundleUtilities failure after the above fixes, and I 
noticed it unconditionally removes rpaths.
Is there a reason for that?

If the user does 
set_target_properties(testbundleutils1 module1 PROPERTIES
  INSTALL_RPATH ${CMAKE_CURRENT_BINARY_DIR}/testdir1
  BUILD_WITH_INSTALL_RPATH 1)

The new BundleUtilities.cmake will strip that rpath.
The attempt to strip those rpaths fails on OS X 10.5, because install_name_tool 
does not recognize  the -delete_rpath.
The test fails because the -id and -change portion of the install_name_tool 
command is prevented by the error from the use of -delete_rpath.

Perhaps we can separate the -delete_rpath part into its own call to 
install_name_tool.  If it fails, the failure can be ignored (as it previously 
ignored install_name_tool failures).  Or maybe there is another idea.

Clint
-- 

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] Forcing colorization of output from cmake

[Brad King]

On 10/08/2014 02:36 PM, Paul Smith wrote:
 Hi all.  Attached please find a proposed patch for the above.  I still
 think there's some slightly awkward redundancy between AssumeTTY and the
 new ForceTTY, but I'm not sure these can actually be combined into one
 flag... certainly not without reworking more of how AssumeTTY is
 interpreted and used than I felt confident with.

In this hunk:

 @@ -68,14 +68,16 @@ void kwsysTerminal_cfprintf(int color, FILE* stream, 
 const char* format, ...)
  #if defined(KWSYS_TERMINAL_SUPPORT_CONSOLE)
CONSOLE_SCREEN_BUFFER_INFO hOutInfo;
HANDLE hOut = kwsysTerminalGetStreamHandle(stream);
 -  if(GetConsoleScreenBufferInfo(hOut, hOutInfo))
 +  if(color  kwsysTerminal_Color_ForceTTY ||
 + GetConsoleScreenBufferInfo(hOut, hOutInfo))
  {
  pipeIsConsole = 1;
  kwsysTerminalSetConsoleColor(hOut, hOutInfo, stream, color);
  }

we cannot enter the if() block unless GetConsoleScreenBufferInfo
returns true because otherwise the hOutInfo will not be initialized
correctly.  In the Windows console code path we really need a handle
to the console from the stream or it cannot work.  Also, once the
pipeIsConsole value is true, the kwsysTerminalSetVT100Color code
path should not be used, so we do not want to force the second code
path either.  Instead ForceTTY should just influence the return
value of kwsysTerminalStreamIsVT100.

The Source/kwsys part of the change actually belongs in a separate
KWSys upstream first.  I've added a modified version of your change
for upstream review and testing here:

 http://review.source.kitware.com/17578

Please try out that version with the rest of your changes.

 it's darn handy to have this just work without having to export
 COLOR='$(if $(MAKE_TERMOUT),FORCE)' in your ~/.bashrc or whatever.
 There's no GNU Makefiles generator, and I couldn't come up with a good
 way to implement this in the generic Unix Makefiles generator.

We already have a CMAKE_COLOR_MAKEFILE option.  Perhaps instead
of just ON or OFF values it could have a GNU value that enables
this behavior.  When initializing it in CMakeGenericSystem.cmake
perhaps it is possible to detect if CMAKE_MAKE_PROGRAM is a GNU
make tool and provide a good default.

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-developers] [PATCH] Preinstall requirements support for CPack RPM generator

[Brad King]

On 10/08/2014 01:48 PM, Evgeny Kalishenko wrote:
 I was interested in feature request
 http://public.kitware.com/Bug/view.php?id=14769 and made a
 simple patch for CPack RPM generator (attached).

Thanks.

In this hunk:

 +# The following keywords require braces around the pre or post 
 suffix in the final RPM spec file.
 +if(${_RPM_SPEC_HEADER} MATCHES REQUIRES_PRE  OR  
 ${_RPM_SPEC_HEADER} MATCHES REQUIRES_POST)
 +  string(REPLACE _ ( _PACKAGE_HEADER_NAME ${_PACKAGE_HEADER_NAME})
 +  set(_PACKAGE_HEADER_NAME ${_PACKAGE_HEADER_NAME}))
 +endif()

The MATCHES conditions can use simply STREQUAL instead.
I'm not very familiar with the spec format, so please
explain the purpose of the s/_/(/ subsitution in comments
here.

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-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

[clinton]

- Original Message -
 Adam,
 
 On 10/08/2014 12:17 PM, Clinton Stimpson wrote:
  Yeah.  I'm curious if changes to BundleUtilities.cmake in fix-OSX-bundle-
  rpaths-and-Qt5 will gracefully handle the BundleUtilities test case with
  @rpath on OS X 10.5.  Perhaps it'll recognize there is no need to change
  rpaths.
 
 The BundleUtilities test still fails on OS X 10.5:
 
  http://open.cdash.org/testDetails.php?test=285651145build=3522021
  -- 6/10: fixing up
  
 '/.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/testbundleutils1'
  install_name_tool: more than one input file specified
  (/.../Tests/BundleUtilities/testdir1 and -delete_rpath)
  Usage: install_name_tool [-change old new] ... [-id name] input
 
 Clinton's changes in his rpath-osx-10_6 extension topic to yours teach
 other uses of -delete_rpath to warn on OS X 10.5 and skip deletion.
 I think something similar will be needed here.  Please investigate.
 
 Meanwhile, on my local OS X 10.9 machine I added this patch:
 
 diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake
 index eedab44..80e5d3b 100644
 --- a/Modules/BundleUtilities.cmake
 +++ b/Modules/BundleUtilities.cmake
 @@ -755,6 +755,7 @@ function(fixup_bundle_item resolved_embedded_item exepath
 dirs)
#
if(changes)
  execute_process(COMMAND install_name_tool ${changes}
  ${resolved_embedded_item})
 +message(STATUS CHANGE install_name_tool ${changes}
 \${resolved_embedded_item}\)
endif()
  endfunction()
 
 From the test output I can see that it is trying to delete several
 rpath entries that do not exist and therefore do not need deletion.
 How is the list chosen for each binary?
 

Brad,

When I do the same message(), I don't see deletion of rpaths which do not exist.
I see deletions of rpaths which do exist as defined in the CMakeLists.txt file:
set_target_properties(testbundleutils1 module1 PROPERTIES
  INSTALL_RPATH ${CMAKE_CURRENT_BINARY_DIR}/testdir1
  BUILD_WITH_INSTALL_RPATH 1)

But, I'm wondering if INSTALL_RPATH should only be effective on OS X if 
MACOSX_RPATH is set.
Currently MACOSX_RPATH determines whether a target uses @rpath for its id, 
which can result in rpaths for a consumer.
In other words, whether a target has rpaths is determined by the use of @rpath 
in its dependencies.
What do you think about the case of INSTALL_RPATH?

Clint
-- 

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] fix-OSX-bundle-rpaths-and-Qt5 topic

[Brad King]

On 10/09/2014 10:16 AM, clin...@elemtech.com wrote:
 When I do the same message(), I don't see deletion of rpaths which do not 
 exist.

I see them for libshared and libshared2 which have SKIP_BUILD_RPATH.

 But, I'm wondering if INSTALL_RPATH should only be effective on OS X
 if MACOSX_RPATH is set.
 Currently MACOSX_RPATH determines whether a target uses @rpath for
 its id, which can result in rpaths for a consumer.
 In other words, whether a target has rpaths is determined by the
 use of @rpath in its dependencies.
 What do you think about the case of INSTALL_RPATH?

If any dependencies have @rpath then the RPATH of a target is
meaningful, and INSTALL_RPATH is how the actual search paths
listed in the RPATH are to be set.  INSTALL_RPATH is orthogonal
to MACOSX_RPATH.  The affect different fields of their target.

-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] fix-OSX-bundle-rpaths-and-Qt5 topic

[Adam Strzelecki]

 I was looking at the BundleUtilities failure after the above fixes, and I 
 noticed it unconditionally removes paths.

It does that because all bundles frameworks/libraries are referenced by 
@executable/loader_path and all @rpath references will be replaced, so there no 
point to have LC_RPATH in executables that will likely point to absolute old 
library locations.

Please note that this is just an extension to existing BundleUtilities 
behavior. I intentionally didn't want to support or add an option to bundle 
framework using @path + LC_PATH.

--Adam
-- 

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] fix-OSX-bundle-rpaths-and-Qt5 topic

[Clinton Stimpson]

On Thursday, October 09, 2014 10:27:32 AM Brad King wrote:
 On 10/09/2014 10:16 AM, clin...@elemtech.com wrote:
  When I do the same message(), I don't see deletion of rpaths which do not
  exist.
 I see them for libshared and libshared2 which have SKIP_BUILD_RPATH.
 
  But, I'm wondering if INSTALL_RPATH should only be effective on OS X
  if MACOSX_RPATH is set.
  Currently MACOSX_RPATH determines whether a target uses @rpath for
  its id, which can result in rpaths for a consumer.
  In other words, whether a target has rpaths is determined by the
  use of @rpath in its dependencies.
  What do you think about the case of INSTALL_RPATH?
 
 If any dependencies have @rpath then the RPATH of a target is
 meaningful, and INSTALL_RPATH is how the actual search paths
 listed in the RPATH are to be set.  INSTALL_RPATH is orthogonal
 to MACOSX_RPATH.  The affect different fields of their target.
 

Another justification for that is if a target does not link to any libraries 
with an @rpath id, it is still useful to have an rpath to support 
dlopen(@rpath/somelib).

Thanks,
Clint
-- 

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 0015201]: Xcode generator is unusably slow on large projects

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=15201 
== 
Reported By:Simon
Assigned To:
== 
Project:CMake
Issue ID:   15201
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2014-10-09 11:07 EDT
Last Modified:  2014-10-09 11:07 EDT
== 
Summary:Xcode generator is unusably slow on large projects
Description: 
I am building a large project, over a thousand CMakeList.txt files resulting in
hundreds of Xcode projects being generated.  This takes at least 6 times longer
than the same makefile generation.

I have profiled cmake 3.0.2 and found a significant bottleneck in
cmGlobalXCodeGenerator::FindXCodeTarget() because the objects are stored in a
vector and this vector has to be iterated over each time to find a target.  This
is done thousands of times in the course of generating the Xcode project.

As a quick fix I did the following:

cmGlobalXCodeGenerator.h, added member var:
std::unordered_mapconst cmTarget*, cmXCodeObject* mXcodeObjectMap;

cmGlobalXCodeGenerator.cpp
void cmGlobalXCodeGenerator::ClearXCodeObjects()
added to end of method: mXcodeObjectMap.clear();

cmGlobalXCodeGenerator::CreateUtilityTarget(cmTarget cmtarget)
Under call to target-SetTarget(...) added: mXcodeObjectMap[cmtarget] = target;

cmGlobalXCodeGenerator::CreateXCodeTarget(...)
Under call to target-SetTarget(...) added: mXcodeObjectMap[cmtarget] = target;

cmXCodeObject* cmGlobalXCodeGenerator::FindXCodeTarget(cmTarget const* t)
rewrote to:
cmXCodeObject* cmGlobalXCodeGenerator::FindXCodeTarget(cmTarget const* t)
{
  if(!t)
{
return 0;
}
  
  std::unordered_mapconst cmTarget*, cmXCodeObject*::iterator iter =
mXcodeObjectMap.find(t);
  if (iter == mXcodeObjectMap.end())
  {
return 0;
  }
  return iter-second;
}
So basically rather than constantly iterating through a vector for the Xcode
object with the right target, it now keeps an unordered map where the key is the
target pointer, and the object is the Xcode object. This reduces the lookup time
enormously.

With only this change the generation of the project I'm working on goes down
from well over an hour to around 10 mins, which puts it inline with the makefile
generator performance.

Steps to Reproduce: 
Build a large set of projects.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2014-10-09 11:07 Simon  New 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] fix-OSX-bundle-rpaths-and-Qt5 topic

[Adam Strzelecki]

FYI pushed e646a14f61 BundleUtilities: Check install_name_tool has 
-delete_rpath which is safest way to check if we can use -delete_rpath as it 
was introduced somewhere in 10.6 SDK, but there's no guarantee what SDK user 
has even it runs more recent OSX.

--Adam
-- 

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] fix-OSX-bundle-rpaths-and-Qt5 topic

[Brad King]

On 10/09/2014 11:14 AM, Adam Strzelecki wrote:
 FYI pushed e646a14f61 BundleUtilities: Check install_name_tool
 has -delete_rpath which is safest way to check if we can use

Thanks.  I moved the commit over on top of the rpath-osx-10_6
topic and then removed that topic.  For now
fix-OSX-bundle-rpaths-and-Qt5 will contain all these related
changes.  I merged it for testing in 'next'.

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-developers] [PATCH] Preinstall requirements support for CPack RPM generator

[Evgeny Kalishenko]

Ok, thanks for the advise about STREQUAL. Explanation of s/_/(/ (from
http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html):
Recent versions of RPM support context marked dependencies. This is a
special type of a dependency that applies only in a specified *context*.
Using this feature, one can specify dependencies for pre- and
post(un)install scriptlets, ie. the context of a dependency is the
execution time of the specified scriptlet.

The syntax for specifying these dependencies is:

Requires(*X*): foo

 Here, *X* can be one of *pre*, *post*, *preun*, or *postun*, which tells
RPM that the package depends on package foo for running the corresponding
*%pre*, *%post*, *%preun*, or *%postun* script.

Modified patch attached.

2014-10-09 18:03 GMT+04:00 Brad King brad.k...@kitware.com:

 On 10/08/2014 01:48 PM, Evgeny Kalishenko wrote:
  I was interested in feature request
  http://public.kitware.com/Bug/view.php?id=14769 and made a
  simple patch for CPack RPM generator (attached).

 Thanks.

 In this hunk:

  +# The following keywords require braces around the pre or post
 suffix in the final RPM spec file.
  +if(${_RPM_SPEC_HEADER} MATCHES REQUIRES_PRE  OR
 ${_RPM_SPEC_HEADER} MATCHES REQUIRES_POST)
  +  string(REPLACE _ ( _PACKAGE_HEADER_NAME
 ${_PACKAGE_HEADER_NAME})
  +  set(_PACKAGE_HEADER_NAME ${_PACKAGE_HEADER_NAME}))
  +endif()

 The MATCHES conditions can use simply STREQUAL instead.
 I'm not very familiar with the spec format, so please
 explain the purpose of the s/_/(/ subsitution in comments
 here.

 Thanks,
 -Brad




-- 
С уважением,
Евгений Калишенко
From 0f05b7863f5db20a9099bf1076df880d7bc68f65 Mon Sep 17 00:00:00 2001
From: evgenyk ydgins...@gmail.com
Date: Wed, 8 Oct 2014 21:39:19 +0400
Subject: [PATCH 1/2] Requires for pre(post) install scripts are implemented
 for RPM packager

---
 Modules/CPackRPM.cmake | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/Modules/CPackRPM.cmake b/Modules/CPackRPM.cmake
index 2864b21..27c5f51 100644
--- a/Modules/CPackRPM.cmake
+++ b/Modules/CPackRPM.cmake
@@ -135,6 +135,31 @@
 #
 #   rpm -qp --requires file.rpm
 #
+# .. variable:: CPACK_RPM_PACKAGE_REQUIRES_PRE
+#
+#  RPM spec requires(pre) field.
+#
+#  * Mandatory : NO
+#  * Default   : -
+#
+#  May be used to set RPM preinstall dependencies (requires(pre)).  Note that you must enclose
+#  the complete requires string between quotes, for example::
+#
+#   set(CPACK_RPM_PACKAGE_REQUIRES_PRE shadow-utils, initscripts)
+#
+# .. variable:: CPACK_RPM_PACKAGE_REQUIRES_POST
+#
+#  RPM spec requires(post) field.
+#
+#  * Mandatory : NO
+#  * Default   : -
+#
+#  May be used to set RPM postinstall dependencies (requires(post)).  Note that you must enclose
+#  the complete requires string between quotes, for example::
+#
+#   set(CPACK_RPM_PACKAGE_REQUIRES_PRE shadow-utils, initscripts)
+#
+#
 # .. variable:: CPACK_RPM_PACKAGE_SUGGESTS
 #
 #  RPM spec suggest field.
@@ -556,7 +581,7 @@ endif()
 # There may be some COMPONENT specific variables as well
 # If component specific var is not provided we use the global one
 # for each component
-foreach(_RPM_SPEC_HEADER URL REQUIRES SUGGESTS PROVIDES OBSOLETES PREFIX CONFLICTS AUTOPROV AUTOREQ AUTOREQPROV)
+foreach(_RPM_SPEC_HEADER URL REQUIRES SUGGESTS PROVIDES OBSOLETES PREFIX CONFLICTS AUTOPROV AUTOREQ AUTOREQPROV REQUIRES_PRE REQUIRES_POST)
 if(CPACK_RPM_PACKAGE_DEBUG)
   message(CPackRPM:Debug: processing ${_RPM_SPEC_HEADER})
 endif()
@@ -595,6 +620,11 @@ foreach(_RPM_SPEC_HEADER URL REQUIRES SUGGESTS PROVIDES OBSOLETES PREFIX CONFLIC
 string(TOLOWER ${_PACKAGE_HEADER_TAIL} _PACKAGE_HEADER_TAIL)
 string(SUBSTRING ${_RPM_SPEC_HEADER} 0 1 _PACKAGE_HEADER_NAME)
 set(_PACKAGE_HEADER_NAME ${_PACKAGE_HEADER_NAME}${_PACKAGE_HEADER_TAIL})
+# The following keywords require braces around the pre or post suffix in the final RPM spec file.
+if(${_RPM_SPEC_HEADER} MATCHES REQUIRES_PRE  OR  ${_RPM_SPEC_HEADER} MATCHES REQUIRES_POST)
+  string(REPLACE _ ( _PACKAGE_HEADER_NAME ${_PACKAGE_HEADER_NAME})
+  set(_PACKAGE_HEADER_NAME ${_PACKAGE_HEADER_NAME}))
+endif()
 if(CPACK_RPM_PACKAGE_DEBUG)
   message(CPackRPM:Debug: User defined ${_PACKAGE_HEADER_NAME}:\n ${CPACK_RPM_PACKAGE_${_RPM_SPEC_HEADER}_TMP})
 endif()
@@ -991,6 +1021,8 @@ Group:  \@CPACK_RPM_PACKAGE_GROUP\@
 Vendor: \@CPACK_RPM_PACKAGE_VENDOR\@
 \@TMP_RPM_URL\@
 \@TMP_RPM_REQUIRES\@
+\@TMP_RPM_REQUIRES_PRE\@
+\@TMP_RPM_REQUIRES_POST\@
 \@TMP_RPM_PROVIDES\@
 \@TMP_RPM_OBSOLETES\@
 \@TMP_RPM_CONFLICTS\@
-- 
1.8.1.4


From b3eedb616170ff1633ec2fb99b3daf2f4a3fa0a4 Mon Sep 17 00:00:00 2001
From: evgenyk ydgins...@gmail.com
Date: Thu, 9 Oct 2014 21:29:18 +0400
Subject: [PATCH 2/2] PREUN and POSTUN requirements implemented for CPackRPM

---
 Modules/CPackRPM.cmake | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git 

Re: [cmake-developers] Preparing for CMake 3.1.0-rc1

[Chuck Atkins]

Are we still on a stage freeze until the release, or is it just a hold on
stage/next?

I ask because I've got a non-trivial branch to push to the stage for review
that re-factors how search paths are constructed for find* commands.

- Chuck

On Tue, Oct 7, 2014 at 10:43 AM, Brad King brad.k...@kitware.com wrote:

 On 10/03/2014 08:27 AM, Brad King wrote:
  In preparation for the first 3.1 release candidate I will feature-
  freeze master as of 2014-10-09.  As of now there are several open
  topics in 'next' that we should try to land in master by then, but
  please refrain from adding non-trivial changes in the meantime.

 In order to get the dashboard cleaned up for final merges to
 'master' before the release, please refrain from merging any
 changes other than dashboard fixes and documentation updates
 to 'next'.

 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

-- 

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] Preparing for CMake 3.1.0-rc1

[Brad King]

On 10/09/2014 02:27 PM, Chuck Atkins wrote:
 I've got a non-trivial branch to push to the stage for review

You can push it for review but please do not merge to 'next' yet.

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-developers] Preparing for CMake 3.1.0-rc1

[Chuck Atkins]

Great, thanks!

- Chuck

On Thu, Oct 9, 2014 at 2:32 PM, Brad King brad.k...@kitware.com wrote:

 On 10/09/2014 02:27 PM, Chuck Atkins wrote:
  I've got a non-trivial branch to push to the stage for review

 You can push it for review but please do not merge to 'next' yet.

 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

[cmake-developers] Refactoring search path construction

[Chuck Atkins]

I've just pushed a branch to the stage for review:
refactor-search-path-construction , not merged to next due to the current
release hold.

Just a head's up, it's rather invasive.  It's a re-factoring of how search
paths get constructed for find* commands.  Up until now, search paths have
been incrementally constructed with the composite search path being the
only result.  This separates and constructs each class of search path
separately and combines them together afterwards.

This branch is a pre-cursor for new features that can manipulate groups of
search paths with leaving others untouched.

- Chuck
-- 

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] Refactoring search path construction

[Chuck Atkins]

Just to clarify, this does *NOT* change the search order.

- Chuck

On Thu, Oct 9, 2014 at 2:45 PM, Chuck Atkins chuck.atk...@kitware.com
wrote:

 I've just pushed a branch to the stage for review:
 refactor-search-path-construction , not merged to next due to the current
 release hold.

 Just a head's up, it's rather invasive.  It's a re-factoring of how search
 paths get constructed for find* commands.  Up until now, search paths have
 been incrementally constructed with the composite search path being the
 only result.  This separates and constructs each class of search path
 separately and combines them together afterwards.

 This branch is a pre-cursor for new features that can manipulate groups of
 search paths with leaving others untouched.

 - Chuck

-- 

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] Forcing colorization of output from cmake

[Paul Smith]

Thanks Brad.  I wrote a bunch more below and left it for posterity.
However thinking more about this I wonder if we couldn't make this
simpler.

What I really want is that if MAKE_TERMOUT is set to a non-empty value,
cmake should pretend that it's in a terminal regardless of what isatty()
says.  We can do this easily enough by adding a simple test to
Terminal.c:kwsysTerminalStreamIsVT100() _without_ adding any code
anywhere else:

   /* Check for a valid terminal.  */
   if(!default_vt100)
 {
 ...
 }
+
+  /* If we're being run from GNU make 4.1+ see if IT thinks we have a TTY.  */
+  const char* termout = getenv(MAKE_TERMOUT);
+  if(termout  termout[0] != '\0')
+{
+return 1;
+}

In a way this is gross, certainly, but this function already checks for
environment variable such as TERM, EMACS, etc. which are set by calling
utilities and handles them specially.  So why not MAKE_TERMOUT as well?

That one change is enough for my particular use-case, without any other
changes (don't need a FORCE setting for color).  I think it would be
useful to allow FORCE (I think this is a good capability to provide; as
I mentioned other tools that support colorization such as GCC etc. to
provide an always-type flag) but it would be decoupled from this GNU
make capability.

Thoughts?


On Thu, 2014-10-09 at 09:55 -0400, Brad King wrote:
 The Source/kwsys part of the change actually belongs in a separate
 KWSys upstream first.  I've added a modified version of your change
 for upstream review and testing here:
 
  http://review.source.kitware.com/17578
 
 Please try out that version with the rest of your changes.

OK.  I see that in your version FORCE only comes into effect if we have
a known good terminal (the new code comes after the check for valid
terminal).

Personally I would expect FORCE to be stronger than that, and return
true regardless of TERM settings.  Whether or not it should override
EMACS env.var. I don't know... I'm on the fence.  In my solution I had
it really FORCE; that is, kwsysTerminalStreamIsVT100() effectively
always was true if --switch=FORCE, regardless of EMACS or TERM.

I'm not at all familiar with Windows so I have no strong opinions on
whether FORCE should also force color output on a Windows console...
although I know a number of people who do use GNU make on Windows and
the Windows port of GNU make does set MAKE_TERMOUT properly.

  it's darn handy to have this just work without having to export
  COLOR='$(if $(MAKE_TERMOUT),FORCE)' in your ~/.bashrc or whatever.
  There's no GNU Makefiles generator, and I couldn't come up with a good
  way to implement this in the generic Unix Makefiles generator.
 
 We already have a CMAKE_COLOR_MAKEFILE option.  Perhaps instead
 of just ON or OFF values it could have a GNU value that enables
 this behavior.  When initializing it in CMakeGenericSystem.cmake
 perhaps it is possible to detect if CMAKE_MAKE_PROGRAM is a GNU
 make tool and provide a good default.

Well, it's easy enough to detect if CMAKE_MAKE_PROGRAM is GNU make, if
we can run it to test the output of ${CMAKE_MAKE_PROGRAM} --version.

The question is, what do you do in the generated makefile if you see
that it's GNU make?  Anything you'd generate into the makefile that
could choose to set --switch=FORCE would have to be GNU-specific (I
can't think of a way to write it using POSIX standard makefile syntax).
It would need to be the equivalent of:

   --switch=$(or $(COLOR),$(if $(MAKE_TERMOUT),FORCE))

to preserve the current behavior, where the COLOR variable setting can
be inherited from the environment.

What if someone runs cmake and it detects GNU make, but then they run
/my/other/make which is not GNU make?  That would work fine now but
fail if we generated GNU-specific content in 'Unix Makefiles'
generators.

If we had a different generator, like 'GNU Makefiles' for example, then
people who chose that would clearly expect the results would only work
with GNU make, but we don't have that.

-- 

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] Initial Attempt at Green Hill MULTI IDE Generator Support

[Geoffrey Viola]

Attached is a patch to make CMake generate files for the Green Hills MULTI IDE. 
These patches are in reference to this feature request: 
http://public.kitware.com/Bug/view.php?id=14992.

There were some limitations. It has been restricted to Windows, because that is 
the version of the IDE that I have. There is a special grouping called a 
Monolith that includes several executables, shared libraries, and the kernel. 
These monoliths have their own set of compile options. I'm not sure how CMake 
would be able to create these. Also, there are some internal macros that point 
to the compiler's target BSP and OS that are currently populated via CMake 
variables: GHS_CUSTOMIZATION, GHS_OS_DIR, and GHS_BSP_NAME.

Any feedback would be appreciated.

Thanks,
[cid:image001.png@01CE6DA0.CA468FE0]



Geoffrey Viola

Software Engineer

T



+1.435.755.2980



ext 1077

M



+1.215.896.6521





asirobots.comhttp://www.asirobots.com/





This message contains confidential information and is intended only for the 
recipient. If you are not the named addressee you should not disseminate, 
distribute or copy this e-mail. Please notify the sender immediately if you 
have received this e-mail by mistake and delete this e-mail from your system. 
Finally, the recipient should check this email and any attachments for the 
presence of viruses. The company accepts no liability for any damage caused by 
any virus transmitted by this email.


0002-Updated-supplementary-files-to-include-the-GHS-gener.patch
Description: 0002-Updated-supplementary-files-to-include-the-GHS-gener.patch


0001-Added-basic-and-partial-support-for-a-Green-Hill-MUL.patch
Description: 0001-Added-basic-and-partial-support-for-a-Green-Hill-MUL.patch
-- 

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