[cmake-developers] [PATCH] FindOpenSSL: Imported Targets Release Note

[Konstantin Podsvirov]

Hello, dear developers!

With this commit the module provides :
http://cmake.org/gitweb?p=cmake.git;a=commit;h=a0dab7b774d5b7a619fd26926c2faf11f9d70309

Then I forgot to reflect this in the release notes.

Patch attached.

--
Regards,
Konstantin PodsvirovFrom 12762e88f9961785c0f5484b01afb957c43ff798 Mon Sep 17 00:00:00 2001
From: Konstantin Podsvirov 
Date: Tue, 29 Sep 2015 08:11:04 +0300
Subject: [PATCH] FindOpenSSL: Imported Targets Release Note

---
 Help/release/dev/FindOpenSSL-imported-targets.rst | 4 
 1 file changed, 4 insertions(+)
 create mode 100644 Help/release/dev/FindOpenSSL-imported-targets.rst

diff --git a/Help/release/dev/FindOpenSSL-imported-targets.rst b/Help/release/dev/FindOpenSSL-imported-targets.rst
new file mode 100644
index 000..0c4767a
--- /dev/null
+++ b/Help/release/dev/FindOpenSSL-imported-targets.rst
@@ -0,0 +1,4 @@
+FindOpenSSL-imported-targets
+
+
+* The :module:`FindOpenSSL` module now provides imported targets.
-- 
2.5.0.windows.1

-- 

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] CXX_STANDARD and linking

[Stephen Kelly]

Brad King wrote:

> On 09/28/2015 03:55 AM, CHEVRIER, Marc wrote:
>> Anyway, the main problem is the fact that, currently, C++ standard
>> handling is not usable on Solaris. Do have any plan to fix this problem
>> anytime soon?
>> 
>> On 25/09/15 17:24, "Brad King" wrote:
>>> Compiling with a -std= flag should link with such a flag too.
>>> Flags like this are why CMake has always passed CMAKE_CXX_FLAGS
>>> to the C++ compiler when using it to drive the linker.  This does
>>> not appear to be the case anywhere right now when the flag is added
>>> via CXX_STANDARD.
> 
> Steve?  According to cmake-compile-features(7) you tested this with
> Oracle SolarisStudio version 12.4.  However, our dashboard covered
> only up through 12.3.

Yes, I tested it on SolarisStudio 12.4, but on linux (Ubuntu). Perhaps 
that's a relevant difference from 'real' Solaris.

Thanks,

Steve.


-- 

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] CXX_STANDARD and linking

[Brad King]

On 09/28/2015 02:34 PM, Stephen Kelly wrote:
>> Steve?  According to cmake-compile-features(7) you tested this with
>> Oracle SolarisStudio version 12.4.
> 
> Yes, I tested it on SolarisStudio 12.4, but on linux (Ubuntu). Perhaps 
> that's a relevant difference from 'real' Solaris.

That seems to be the case.  The interaction with C++ runtime library
selection may differ.

Although we had dashboard builds for SolarisStudio 12.3 on SunOS the
compiler feature/standard logic is enabled only for SunPro 5.13 and
above which do not appear until SolarisStudio 12.4.

On 09/28/2015 01:42 PM, Brad King wrote:
> The logic in cmLocalGenerator::AddCompileOptions that selects the final
> _STANDARD level and adds a flag for it may need to be factored
> out into a separate step (in Compute?) that selects the level.  Then
> AddCompileOptions can continue to add the compiler flag and we'll need
> new code to add link-time compiler-driver flags based on the selected
> standard level.

Steve, does using _STANDARD to put -std= flags on the link line
seem like the right approach to fix this?

This won't be done before CMake 3.4 so for now we should look at
turning off all language standard and compile feature support for
SolarisStudio when not hosted on Linux.

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] CXX_STANDARD and linking

[Brad King]

On 09/28/2015 03:55 AM, CHEVRIER, Marc wrote:
> Anyway, the main problem is the fact that, currently, C++ standard handling
> is not usable on Solaris. Do have any plan to fix this problem anytime soon?
> 
> On 25/09/15 17:24, "Brad King" wrote:
>> Compiling with a -std= flag should link with such a flag too.
>> Flags like this are why CMake has always passed CMAKE_CXX_FLAGS
>> to the C++ compiler when using it to drive the linker.  This does
>> not appear to be the case anywhere right now when the flag is added
>> via CXX_STANDARD.

Steve?  According to cmake-compile-features(7) you tested this with
Oracle SolarisStudio version 12.4.  However, our dashboard covered
only up through 12.3.

The logic in cmLocalGenerator::AddCompileOptions that selects the final
_STANDARD level and adds a flag for it may need to be factored
out into a separate step (in Compute?) that selects the level.  Then
AddCompileOptions can continue to add the compiler flag and we'll need
new code to add link-time compiler-driver flags based on the selected
standard level.

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] Adding Windows 10 support

[Gilles Khouzam]

The more I think about it, the more this makes sense and should work out well.

Let me take your current changes and adapt them for this and test them out.

-Original Message-
From: Gilles Khouzam 
Sent: Friday, September 25, 2015 14:55
To: 'Brad King' 
Cc: cmake-developers@cmake.org
Subject: RE: [cmake-developers] [Patch] Adding Windows 10 support

You're right, by targeting another version (8.1 or 6.3), the tag would not be 
written. 

Leveraging CMAKE_SYSTEM_VERSION is an interesting idea. Let me mull it over a 
little bit more and see how I would apply to newer SDKs as they come out, as I 
would like to minimize the required changes to CMake to support things when 
they come out (I'm gathering some information on that).


-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Friday, September 25, 2015 11:53
To: Gilles Khouzam 
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support

On 09/25/2015 01:00 PM, Gilles Khouzam wrote:
> This was done deliberately to only force a value for 
> CMAKE_WINDOWS_TARGET_PLATFORM_VERSION

With the approach in my patch that variable is never set by the generator.  It 
chooses a WindowsTargetPlatformVersion value and reports it in 
CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION.
The CMAKE_WINDOWS_TARGET_PLATFORM_VERSION variable is only for the user-defined 
selection.

> when the CMAKE_SYSTEM_VERSION is specified as 10.0.
> Otherwise any Windows 10 machine will use the Windows 10 SDK and not 
> the Windows 8.1 SDK

Why is it wrong to target the host's version by default?
This is commonly done on other platforms.  If one is building only for the 
current host this makes sense.  If one is building for deployment then extra 
care is needed anyway.

> and I'm not sure that there is a way then target the Windows 8.1 SDK.

If one wants to build on a Windows 10 host but target an older version of 
Windows, one can simply do -DCMAKE_SYSTEM_VERSION=6.3 for example.  This is 
thanks to your patch that allows it to be set separately from CMAKE_SYSTEM_NAME.

Actually, why do we need a separate setting like 
CMAKE_WINDOWS_TARGET_PLATFORM_VERSION to select this at all?
Why not just take the highest available SDK that does not exceed 
CMAKE_SYSTEM_VERSION?  CMAKE_SYSTEM_VERSION is meant exactly to specify the 
target OS version.  You posted something about this here:

 https://cmake.org/Bug/view.php?id=15670#c39247

but I do not quite understand it.

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] Timestamp of VS-generator rule files

[Brad King]

On 09/28/2015 09:45 AM, mike.pa...@bmw.de wrote:
> As requested, I put the patch right into the VS10 target generator.

Thanks.  Applied with minor tweaks:

 VS: Prevent generated "rule" files from causing rebuilds
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fa5284f0

-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] [CMake 0015759]: Error running cmake

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15759 
== 
Reported By:Vishnu Makkapati
Assigned To:
== 
Project:CMake
Issue ID:   15759
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   urgent
Status: new
== 
Date Submitted: 2015-09-28 02:49 EDT
Last Modified:  2015-09-28 02:49 EDT
== 
Summary:Error running cmake
Description: 
I get the following error when I run cmake.
Inconsistency detected by ld.so: dl-version.c: 224: _dl_check_map_versions:
Assertion `needed != ((void *)0)' failed!
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-09-28 02:49 Vishnu MakkapatiNew 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] CXX_STANDARD and linking (was: C++11 support broken for SolarisStudio 12.4)

[CHEVRIER, Marc]

Hi,

Bootstrapping CMake with the flags you specify and SOlarisStudio 12.4 enable to 
generate a usable Cmake but some tests are failing with error related to CXX 
standard.
For example, test 32, CompileFeatures generates error:
32: CMake Error: Error required internal CMake variable not set, cmake may be 
not be built correctly.
32: Missing variable is:
32: CMAKE_CXX98_EXTENSION_COMPILE_OPTION

In the meantime, I am using SolarisStudio 12.2 for CMake bootstrapping.

Anyway, the main problem is the fact that, currently, C++ standard handling is 
not usable on Solaris. Do have any plan to fix this problem anytime soon?


After this problem fixed, I hope CMake bootstrapping will be solved as well…

Thank you for your help.

Marc


On 25/09/15 17:24, "Brad King"  wrote:

>Steve,
>
>On 09/25/2015 03:58 AM, CHEVRIER, Marc wrote:
>> * If I add option -std=c++11 in the file .../Test.dir/link.txt,
>>   link is successful 
>
>Compiling with a -std= flag should link with such a flag too.
>Flags like this are why CMake has always passed CMAKE_CXX_FLAGS
>to the C++ compiler when using it to drive the linker.  This does
>not appear to be the case anywhere right now when the flag is added
>via CXX_STANDARD.
>
>Marc, meanwhile you should be able to bootstrap CMake with
>
> bootstrap ... -- -DCMake_NO_C_STANDARD=1 -DCMake_NO_CXX_STANDARD
>
>to skip trying to use any -std= flags.
>
>-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] [CMake 0015760]: Generating project files fails, if compiler path has spaces

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15760 
== 
Reported By:leandros
Assigned To:
== 
Project:CMake
Issue ID:   15760
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2015-09-28 05:43 EDT
Last Modified:  2015-09-28 05:43 EDT
== 
Summary:Generating project files fails, if compiler path has
spaces
Description: 
Generating Unix Makefiles fails, if the compiler path has a space. 

/usr/bin/clang and /usr/bin/clang++ are not symlinked. 

$ CC=/usr/bin/clang CXX=/usr/bin/clang++ cmake -G "Unix Makefiles" ..
-- The C compiler identification is AppleClang 7.0.0.772
-- The CXX compiler identification is AppleClang 7.0.0.772
-- Check for working C compiler: /Applications/Xcode
7.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-- Check for working C compiler: /Applications/Xcode
7.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang --
broken
CMake Error at
/usr/local/Cellar/cmake/3.3.2/share/cmake/Modules/CMakeTestCCompiler.cmake:61
(message):
  The C compiler "/Applications/Xcode
  7.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
  is not able to compile a simple test program.

  It fails with the following output:

   Change Dir:
/Users/arvidgerstmann/cocos2d-x-3.6/external/flatbuffers/build/CMakeFiles/CMakeTmp



  Run Build Command:"/usr/bin/make" "cmTC_d0237/fast"

  /Applications/Xcode 7.app/Contents/Developer/usr/bin/make -f
  CMakeFiles/cmTC_d0237.dir/build.make CMakeFiles/cmTC_d0237.dir/build

  make: /Applications/Xcode: No such file or directory

  make: *** [cmTC_d0237/fast] Error 1





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):



CMake Warning (dev) in CMakeLists.txt:
  No cmake_minimum_required command is present.  A line of code such as

cmake_minimum_required(VERSION 3.3)

  should be added at the top of the file.  The version specified may be lower
  if you wish to support older CMake versions for this project.  For more
  information run "cmake --help-policy CMP".
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Configuring incomplete, errors occurred!
See also "/build/CMakeFiles/CMakeOutput.log".
See also "/build/CMakeFiles/CMakeError.log".

Steps to Reproduce: 
- Rename "Xcode.app" to "Xcode Test.app"
- Run "sudo xcode-select -switch /Applications/Xcode\ Test.app
- Run cmake, with "Unix Makefiles" generator

Additional Information: 
The "Xcode" generator seems to work, I just have to specify the
"CMAKE_C_COMPILER" and "CMAKE_CXX_COMPILER" defines, due to cmake not yet
supporting Xcode 7 (? works fine with 6).
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-09-28 05:43 leandros   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 fails to identify C and CXX compiler when building universal

[Ryan Schmidt]

Hello, I am a developer with the MacPorts package management system, and I want 
to report to you a bug in cmake 3.3.2 that affects OS X.

I was going to file a bug report in your issue tracker, but the bright yellow 
box at the top of the "report issue" page made it sound like I should send my 
report here instead.

The problem is that cmake cannot identify the compiler, when compiling any 
project (that uses cmake) universally (i.e. for more than one architecture, 
e.g. for both x86_64 and i386):

-- cmake version 3.3.2
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown

This could cause programs that rely on identifying the compiler to either build 
incorrectly or even (e.g. in the case of x265) to fail to build at all. For 
cross-referencing purposes, this problem was previously reported to the 
MacPorts project here:

https://trac.macports.org/ticket/48331

The problem does not occur when compiling non-universally (i.e. for only a 
single architecture, e.g. for only x86_64):

-- The C compiler identification is AppleClang 7.0.0.772
-- The CXX compiler identification is AppleClang 7.0.0.772

I found that in CMakeDetermineCompilerId.cmake, cmake compiles a test program 
(CMAKE_DETERMINE_COMPILER_ID_BUILD) which defines certain strings that describe 
the compiler, and then examines the strings in the compiled a.out file 
(CMAKE_DETERMINE_COMPILER_ID_CHECK). If the file contains more than one 
"INFO:compiler[...]" string, cmake assumes something went wrong and sets 
COMPILER_ID_TWICE to 1 which causes the compiler id to be forgotten.

The problem is that when building universal, the a.out file produced by the 
test will contain multiple copies of the strings -- once for each architecture. 
What the compiler does for you when you use multiple -arch flags is to compile 
the file separately, once for each architecture, then glue the separate files 
together into a single file (using the lipo program), so naturally such a file 
will contain multiple copies of any strings. This is not a bug; this is how 
universal binaries work. The bug is that cmake considers this valid condition 
to be erroneous.

Here is an example of the duplicated strings:

$ lipo -info build/CMakeFiles/3.3.2/CompilerIdC/a.out 
Architectures in the fat file: work/build/CMakeFiles/3.3.2/CompilerIdC/a.out 
are: x86_64 i386
$ strings -arch all build/CMakeFiles/3.3.2/CompilerIdC/a.out 
INFO:compiler[AppleClang]
INFO:platform[Darwin]
INFO:arch[]
INFO:compiler_version[0007...0772]
INFO:compiler[AppleClang]
INFO:platform[Darwin]
INFO:arch[]
INFO:compiler_version[0007...0772]

(I know cmake uses its internal FILE(STRINGS) command, not the strings program, 
but I presume they are similar.)

I was able to get cmake to correctly identify the compilers even when building 
universal by simply removing the COMPILER_ID_TWICE stuff from 
CMakeDetermineCompilerId.cmake, but perhaps you want something more elegant 
that verifies that if there are multiple definitions of a particular info line, 
all the definitions are the same.

-- 

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] [Patch] Timestamp of VS-generator rule files

[Mike.Pagel]

As requested, I put the patch right into the VS10 target generator. Please note 
that this requires a new dependency on , which was _not_ there 
before. I tried to stick to the existing style. Please let me know if I need to 
use different APIs or anything else needs to be improved.

Thanks,
Mike

-Ursprüngliche Nachricht-
Von: cmake-developers [mailto:cmake-developers-boun...@cmake.org] Im Auftrag 
von Brad King
Gesendet: Freitag, 25. September 2015 14:34
An: cmake-developers@cmake.org
Betreff: Re: [cmake-developers] Timestamp of VS-generator rule files

On 09/25/2015 07:45 AM, mike.pa...@bmw.de wrote:
> I wrote a small function OutdateFileTime(const std::string& filename)
> which does what it sounds like. It is called by the VS generator right
> after rule file creation with Touch. I wasn't sure whether this function,
> which uses Win32 API should go into the generator code or SystemTools.

Until the functionality is needed elsewhere I see no reason not to just
put it right in the generator implementation.  If a more general purpose
for it is found later it can be refactored over to SystemTools and made
to work on more platforms.  No need for that yet though.

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


vs-old-rule-files.patch
Description: vs-old-rule-files.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