[cmake-developers] [CMake 0014856]: cannot build cmake on Solaris
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14856 == Reported By:Eugene M. Zheganin Assigned To: == Project:CMake Issue ID: 14856 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2014-04-01 02:50 EDT Last Modified: 2014-04-01 02:50 EDT == Summary:cannot build cmake on Solaris Description: Solaris 11.1 SRU 17.5 GCC 4.5.2 build crashes: [...] -- Build files have been written to: /home/emz/src/cmake-2.8.12.2 - CMake has bootstrapped. Now run gmake. root@sol:/home/emz/src/cmake-2.8.12.2# gmake Scanning dependencies of target cmIML_test [ 0%] Building C object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test.c.o [ 1%] Building C object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_ABI_C.c.o [ 1%] Building C object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_INT_C.c.o [ 1%] Building C object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_include_C.c.o [ 1%] Building CXX object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_ABI_CXX.cxx.o [ 1%] Building CXX object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_INT_CXX.cxx.o [ 2%] Building CXX object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_include_CXX.cxx.o Linking CXX executable cmIML_test [ 2%] Built target cmIML_test Scanning dependencies of target cmsys [ 2%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/ProcessUNIX.c.o [ 3%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/Base64.c.o [ 3%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/MD5.c.o [ 3%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/Terminal.c.o [ 3%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/System.c.o [ 4%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/String.c.o [ 4%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/Directory.cxx.o [ 4%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/DynamicLoader.cxx.o [ 4%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/Glob.cxx.o [ 4%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/RegularExpression.cxx.o [ 5%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/SystemTools.cxx.o [ 5%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/CommandLineArguments.cxx.o [ 5%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/IOStream.cxx.o [ 5%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/SystemInformation.cxx.o /home/emz/src/cmake-2.8.12.2/Source/kwsys/SystemInformation.cxx: In member function ‘std::string cmsys::unnamed::SymbolProperties::Demangle(const char*) const’: /home/emz/src/cmake-2.8.12.2/Source/kwsys/SystemInformation.cxx:1460:5: error: ‘abi’ has not been declared /home/emz/src/cmake-2.8.12.2/Source/kwsys/SystemInformation.cxx: In member function ‘void cmsys::unnamed::SymbolProperties::Initialize(void*)’: /home/emz/src/cmake-2.8.12.2/Source/kwsys/SystemInformation.cxx:1478:3: error: ‘Dl_info’ was not declared in this scope /home/emz/src/cmake-2.8.12.2/Source/kwsys/SystemInformation.cxx:1478:11: error: expected ‘;’ before ‘info’ /home/emz/src/cmake-2.8.12.2/Source/kwsys/SystemInformation.cxx:1479:34: error: ‘info’ was not declared in this scope /home/emz/src/cmake-2.8.12.2/Source/kwsys/SystemInformation.cxx:1479:38: error: ‘dladdr’ was not declared in this scope /home/emz/src/cmake-2.8.12.2/Source/kwsys/SystemInformation.cxx: In static member function ‘static std::string cmsys::SystemInformationImplementation::GetProgramStack(int, int)’: /home/emz/src/cmake-2.8.12.2/Source/kwsys/SystemInformation.cxx:3631:41: error: ‘backtrace’ was not declared in this scope gmake[2]: *** [Source/kwsys/CMakeFiles/cmsys.dir/SystemInformation.cxx.o] Error 1 gmake[1]: *** [Source/kwsys/CMakeFiles/cmsys.dir/all] Error 2 gmake: *** [all] Error 2 cmake 2.8.11.2 builds fine, some older versions too (tried 2.6.4). == Issue History Date ModifiedUsername FieldChange == 2014-04-01 02:50 Eugene M. ZheganinNew 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
Re: [cmake-developers] [CMake] Fwd: [PATCH] Add support for Metro apps
From: Dan Kegel d...@kegel.com Sent: Mon, Mar 31, 2014 10:20 am On Mon, Mar 31, 2014 at 7:13 AM, David Cole dlrd...@aol.com wrote: It will be cool to be able to build Metro apps using CMake. Well, aside from the obvious problem :-) Well .. obviously. ;-) -- 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/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014857]: Allow COMPILE_OPTIONS to vary by source file language
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14857 == Reported By:Stephen Kelly Assigned To: == Project:CMake Issue ID: 14857 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2014-04-01 10:15 EDT Last Modified: 2014-04-01 10:15 EDT == Summary:Allow COMPILE_OPTIONS to vary by source file language Description: Compile options like -fno-exceptions should be added for CXX files, but not for C files. http://thread.gmane.org/gmane.comp.kde.devel.frameworks/9222/focus=8215 http://thread.gmane.org/gmane.comp.compilers.llvm.cvs/173869 Some methods like cmLocalGenerator::GetIncludeDirectories have a language in their API, but that is a linker language, not a source file language. Making build properties vary by source file language is probably a large refactoring task of the existing generators. == Issue History Date ModifiedUsername FieldChange == 2014-04-01 10:15 Stephen Kelly 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/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014858]: Flags specified for the compiler do not stay together during processing.
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14858 == Reported By:Michael Priestman Assigned To: == Project:CMake Issue ID: 14858 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2014-04-01 11:51 EDT Last Modified: 2014-04-01 11:51 EDT == Summary:Flags specified for the compiler do not stay together during processing. Description: I want to enable code analysis in Visual Studio. To do this, you add the following flags to the compiler: /analyze /analyze:log output.xml When I try to do this with the following snippet of CMake: set(CMAKE_C_FLAGS /analyze /analyze:log output.xml) It mangles the arguments. Firstly, it puts quotes around the log part, and secondly, the output.xml does not follow immediately after the /analyze:log argument, which is a compile error. I have had this working in a previous version of CMake; I think it worked in version 2.8.9, but stopped working in (I think) 2.8.12. Steps to Reproduce: Attached files reproduce the problem with Visual Studio 11 generator. Generate Visual Studio 11 solution and try to build. You'll get a compile error saying /analyze:log requires an argument. == Issue History Date ModifiedUsername FieldChange == 2014-04-01 11:51 Michael PriestmanNew Issue 2014-04-01 11:51 Michael PriestmanFile Added: CMakeAnalyzeError.zip == -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Review Request: Topic ExternalProject_exclude-from-all
On 27/03/14 16:34, Brad King wrote: Yes, but let's do only one change to ExternalProject per day so we can see how the tests do. Thanks for merging the other patch. I just rebased and merged this one to next now. Daniele -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] Fwd: [PATCH] Add support for Metro apps
This is great Paul. I would love nothing more than to combine resources. I'll take a look at your branches to understand what you've done. I'd love to see all these efforts merged together and be available for the community. ~Gilles -Original Message- From: Paul Annetts [mailto:p...@lightunobscured.com] Sent: Tuesday, April 1, 2014 01:13 To: Gilles Khouzam; 'David Cole'; minmin.g...@gmail.com; cmake-developers@cmake.org; cm...@cmake.org Subject: RE: [CMake] Fwd: [PATCH] Add support for Metro apps Hi Gilles, I have done some work to extend CMAKE so that it generates projects that support the different platforms of Windows Phone (x86/ARM) inside a single SLN in exactly this way, and I sent a patch to the dev-list last year. It is currently being used on a large scale cross-platform project I am working on. To David's point it is another full generator (Visual Studio 2012 Windows Phone 8) and doesn't rely on toolchain - so at least it is clear what it is doing. It's been on the back-burner for a bit on my side, as initial support only worked for static libraries and I got busy with other things. Since I last reported I have managed to extend this to Windows Runtime Component DLLs but I have yet to sanitise this for review. This is mainly around getting VS to take care of linking automatically, as CMAKE can't track all the combinations of binaries in all platform architectures. I haven't supported Windows Phone C++/DirectX EXE projects. Minmin: I think the general principles above are extendable to Windows Store Apps: i.e. support for X64 should be trivial. Also be aware that there EXE project types that are not available to Windows Phone that Windows Store supports (e.g. C++/XAML). The code is at: https://github.com/paulannetts/CMake Branches: vs11-multi-platform, windows-phone-8, wp8-runtime-component Hopefully we can pool resources and come up with a good combined solution! Paul Annetts. -Original Message- From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Gilles Khouzam Sent: 31 March 2014 19:25 To: David Cole; minmin.g...@gmail.com; cmake-developers@cmake.org; cm...@cmake.org Subject: Re: [CMake] Fwd: [PATCH] Add support for Metro apps Hi, I'm new to CMake but am looking to help with this effort. I'm wondering if it would make more sense (and if it's possible) to have the WinRT flavors as separate platforms within the same solution as you would get if you create a new WinRT project in Visual Studio, instead of having 3 different configurations. I'm looking at also adding WinRT support for Windows Phone and I think that trying to minimize the generators might make more sense. ~Gilles -Original Message- From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of David Cole Sent: Monday, March 31, 2014 07:13 To: minmin.g...@gmail.com; cmake-developers@cmake.org; cm...@cmake.org Subject: Re: [CMake] Fwd: [PATCH] Add support for Metro apps Thanks for working on this. It will be cool to be able to build Metro apps using CMake. One thing I think is crucial here is to include somewhere an example or test project that actually builds a Metro app, and shows how you have to construct the CMakeLists for it, and any special considerations needed when running CMake to generate the project. Without that, I have no clue where to start on evaluating whether these patches are sufficient or not. Ideally, the example/test will be: - here, use something like this CMakeLists.txt (and then show one) - run CMake with the XXX generator - build as usual Could you add a test/example somewhere that shows how to use this? And now, the following is no criticism of your patch, or your attempts to get this functionality into CMake, *but*: - there are too many ways to cross compile for CMake already, and it would be nice if this way was like one of the other ways rather than something entirely different. Right now, CMake already supports: - true cross-compiling using a makefile based generator and a toolchain file - building universal binaries on OSX, but not with a toolchain file - building iOS apps on OSX, but with special variables and properties that need setting - building 32-bit and 64-bit windows apps from the same source tree, but with VS generators, using 2 different build trees each with a different generator, or with non-VS generators, using 2 different build trees, and different environments to define the tools And now there's this. Which I guess is closest to the VS different generator approach. It would be super awesome if somebody could come up with a coherent way to unify all this. (Steve and Eric: hopefully you are considering making the Android stuff you're about to work on blend in closely with one of these existing models rather than introducing yet another cross-compiling model) My 2 cents -- again: thanks for your contribution and keep up the good work. Overall, CMake is still squarely the best way to
Re: [cmake-developers] [PATCH] cleanup Watcom Windows configuration
I atached patch which cleanup Watcom Windows configuration
Thanks. Since this touches Windows-wcl386.cmake it is tangled
with the link line quoting change. Once that is in 'master'
please rebase this on it and re-send.
Thanks,
-Brad
Hi Brad,
I enclosed updated patch, based to current master.
Regards
Jiri
From 9c9176806df26e5a7f6c9e839091434af3cbec0b Mon Sep 17 00:00:00 2001
From: Jiri Malak malak.j...@gmail.com
Date: Tue, 1 Apr 2014 21:20:41 +0200
Subject: [PATCH] cleanup Watcom Windows configuration
remove Watcom linker caseexact options already defined in system definition
use win_dll system for SHARED_LIBRARY and SHARED_MODULE
use explicit target definition -bt=.. option for proper initialization of
compiler Windows environment (predefined macros)
reorganize compiler options to global options and configuration specific options
use option to optimize out stack checking code for release version
---
Modules/Platform/Windows-wcl386.cmake | 50 +++
1 file changed, 27 insertions(+), 23 deletions(-)
diff --git a/Modules/Platform/Windows-wcl386.cmake
b/Modules/Platform/Windows-wcl386.cmake
index 617761b..72a5929 100644
--- a/Modules/Platform/Windows-wcl386.cmake
+++ b/Modules/Platform/Windows-wcl386.cmake
@@ -12,13 +12,15 @@ else()
set(CMAKE_LIB_QUIET -q)
endif()
+set(CMAKE_EXE_LINKER_FLAGS_INIT)
set(CMAKE_CREATE_WIN32_EXE system nt_win )
set(CMAKE_CREATE_CONSOLE_EXE system nt )
-
-set (CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT debug all )
-set (CMAKE_SHARED_LINKER_FLAGS_DEBUG_INIT debug all )
-set (CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO_INIT debug all )
-set (CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO_INIT debug all )
+set(CMAKE_SHARED_LINKER_FLAGS_INIT system nt_dll)
+set(CMAKE_MODULE_LINKER_FLAGS_INIT system nt_dll)
+foreach(type SHARED MODULE EXE)
+ set(CMAKE_${type}_LINKER_FLAGS_DEBUG_INIT debug all opt map, symfile)
+ set(CMAKE_${type}_LINKER_FLAGS_RELWITHDEBINFO_INIT debug all opt map,
symfile)
+endforeach()
set(CMAKE_C_COMPILE_OPTIONS_DLL -bd) # Note: This variable is a ';'
separated list
set(CMAKE_SHARED_LIBRARY_C_FLAGS -bd) # ... while this is a space separated
string.
@@ -26,18 +28,18 @@ set(CMAKE_SHARED_LIBRARY_C_FLAGS -bd) # ... while this is
a space separated st
set(CMAKE_RC_COMPILER rc )
set(CMAKE_BUILD_TYPE_INIT Debug)
-set (CMAKE_CXX_FLAGS_INIT -w=3 -xs)
-set (CMAKE_CXX_FLAGS_DEBUG_INIT -br -bm -d2)
-set (CMAKE_CXX_FLAGS_MINSIZEREL_INIT -br -bm -os -dNDEBUG)
-set (CMAKE_CXX_FLAGS_RELEASE_INIT -br -bm -ot -dNDEBUG)
-set (CMAKE_CXX_FLAGS_RELWITHDEBINFO_INIT -br -bm -d2 -ot -dNDEBUG)
-set (CMAKE_C_FLAGS_INIT -w=3 )
-set (CMAKE_C_FLAGS_DEBUG_INIT -br -bm -d2 -od)
-set (CMAKE_C_FLAGS_MINSIZEREL_INIT -br -bm -os -dNDEBUG)
-set (CMAKE_C_FLAGS_RELEASE_INIT -br -bm -ot -dNDEBUG)
-set (CMAKE_C_FLAGS_RELWITHDEBINFO_INIT -br -bm -d2 -ot -dNDEBUG)
-set (CMAKE_C_STANDARD_LIBRARIES_INIT library clbrdll.lib library plbrdll.lib
library kernel32.lib library user32.lib library gdi32.lib library winspool.lib
library comdlg32.lib library advapi32.lib library shell32.lib library ole32.lib
library oleaut32.lib library uuid.lib library odbc32.lib library odbccp32.lib)
-set (CMAKE_CXX_STANDARD_LIBRARIES_INIT ${CMAKE_C_STANDARD_LIBRARIES_INIT})
+
+# single/multi-threaded /-bm
+# static/DLL run-time libraries /-br
+# default is setup for multi-threaded + DLL run-time libraries
+set (CMAKE_C_FLAGS_INIT -bt=nt -w3 -dWIN32 -br -bm)
+set (CMAKE_CXX_FLAGS_INIT -bt=nt -xs -w3 -dWIN32 -br -bm)
+foreach(lang C CXX)
+ set (CMAKE_${lang}_FLAGS_DEBUG_INIT -d2)
+ set (CMAKE_${lang}_FLAGS_MINSIZEREL_INIT -s -os -d0 -dNDEBUG)
+ set (CMAKE_${lang}_FLAGS_RELEASE_INIT -s -ot -d0 -dNDEBUG)
+ set (CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT -s -ot -d1 -dNDEBUG)
+endforeach()
foreach(type CREATE_SHARED_LIBRARY CREATE_SHARED_MODULE LINK_EXECUTABLE)
set(CMAKE_C_${type}_USE_WATCOM_QUOTE 1)
@@ -49,29 +51,29 @@ set(CMAKE_C_CREATE_IMPORT_LIBRARY
set(CMAKE_CXX_CREATE_IMPORT_LIBRARY ${CMAKE_C_CREATE_IMPORT_LIBRARY})
set(CMAKE_C_LINK_EXECUTABLE
-wlink ${CMAKE_START_TEMP_FILE} ${CMAKE_WLINK_QUIET} name
'TARGET_UNQUOTED' LINK_FLAGS option caseexact file {OBJECTS}
LINK_LIBRARIES ${CMAKE_END_TEMP_FILE})
+wlink ${CMAKE_START_TEMP_FILE} ${CMAKE_WLINK_QUIET} name
'TARGET_UNQUOTED' LINK_FLAGS file {OBJECTS} LINK_LIBRARIES
${CMAKE_END_TEMP_FILE})
set(CMAKE_CXX_LINK_EXECUTABLE ${CMAKE_C_LINK_EXECUTABLE})
# compile a C++ file into an object file
set(CMAKE_CXX_COMPILE_OBJECT
-CMAKE_CXX_COMPILER ${CMAKE_START_TEMP_FILE} ${CMAKE_WCL_QUIET} FLAGS
-dWIN32 -d+ DEFINES -foOBJECT -c -cc++ SOURCE${CMAKE_END_TEMP_FILE})
+CMAKE_CXX_COMPILER ${CMAKE_START_TEMP_FILE} ${CMAKE_WCL_QUIET} FLAGS
-d+ DEFINES -foOBJECT -c -cc++ SOURCE${CMAKE_END_TEMP_FILE})
# compile a C file into an object file
set(CMAKE_C_COMPILE_OBJECT
-CMAKE_C_COMPILER ${CMAKE_START_TEMP_FILE} ${CMAKE_WCL_QUIET} FLAGS
-dWIN32 -d+ DEFINES -foOBJECT -c -cc
[cmake-developers] [CMake 0014859]: UseSWIG rebuilds source even when the the dependencies have not changed (again)
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14859
==
Reported By:Felix Schwitzer
Assigned To:
==
Project:CMake
Issue ID: 14859
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2014-04-01 17:53 EDT
Last Modified: 2014-04-01 17:53 EDT
==
Summary:UseSWIG rebuilds source even when the the
dependencies have not changed (again)
Description:
This reopens 0010080, as I'm not the original reporter and therefore can't
reopen the bug.
The fix provided in
http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=63ebb1
does not solve the problem of recompiling the python-module again and again, if
the module name is passed via
set_source_files_properties(
${_interfacefile} PROPERTIES
CPLUSPLUS ON
SWIG_FLAGS -DMODULENAME=${_modulename})
The original, reverted, change
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f0111deb
worked for me.
Steps to Reproduce:
See attached example
Additional Information:
I build the bindings almost always for different script languages, iterating
over the languages and passing a modified modulname appropriate to the
selected language in the way mentioned above. A cmake fragment would look
like
set(_iffile ltt.i)
set(_languages ruby python)
foreach(_lang ${_languages})
if(_lang STREQUAL ruby)
set(_modulename rltt)
set(_libs ${RUBY_LIBRARY})
elseif(_lang STREQUAL python)
set(_modulename pyltt)
set(_libs ${PYTHON_LIBRARY})
endif()
set_source_files_properties(
${_iffile} PROPERTIES
CPLUSPLUS ON
SWIG_FLAGS -DMODULENAME=${_modulename})
swig_add_module(${_modulename} ${_lang} ${_iffile})
swig_link_libraries(${_modulename} ltt ${_libs})
endforeach()
==
Issue History
Date ModifiedUsername FieldChange
==
2014-04-01 17:53 Felix SchwitzerNew Issue
2014-04-01 17:53 Felix SchwitzerFile Added: ltt.zip
==
--
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/cgi-bin/mailman/listinfo/cmake-developers
