Re: [cmake-developers] Generating buildsystem metadata from CMake
On Wed, Mar 11, 2015 at 11:10 AM, Stephen Kelly wrote: > Hi, > > Following from the thread here: > > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12394 > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12650 > > I'm starting to gather requirements and make sure the feature is > well designed to satisfy the needs we're already aware of, and fits with > the features CMake currently has. > > The aim is to generate a structured file containing metadata relating the > buildsystem. > > To help with completing the design of this feature, I've written > documentation (documentation driven design), and a unit test > containing a CMakeLists.txt file which exercises many modern CMake > features in the "generate-metadata" branch in my clone. > > Mostly the design I propose can be read in the documentation I wrote. I'm > interested in any feedback. > > > https://gitorious.org/cmake/steveires-cmake/source/generate-metadata:Tests/Metadata/CMakeLists.txt > http://www.steveire.com/cmake-future/manual/cmake-metadata-generation.7.html > > I expect to require a few iterations to figure out what the metadata files > should contain in the end. Note that there are already some differences > between my design and Aleix's implementation, such as that my design > proposes one metadata file per config. There are also some things > missing like location, because it is not yet clear to me whether build > or install locations are needed etc. > > The content of the metadata file is determined by the build properties, and > is necessarily similar to the compile-related content created when > generating the actual buildsystem. It additionally contains information > about the output locations of build artifacts and information relating to > the cmake description itself. > > Goals include: > > * Make it possible for IDEs to access the compile-related information for > autocompletion and code navigation etc purposes. > > * Remove the need for IDEs to parse generated Makefiles or Ninja files to > access compile-related information. The structure of those files is not > 'stable', while the content of the metadata file is stable. > http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/48412 > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11081 > > * Remove the need for users to create a new build directory and new build > in order to use or switch IDEs. QtCreator requires that > the C::B 'extra generator is used as it parses compile information from > that. Other 'extra generators' such as for eclipse, sublime, kate etc > also require fresh/new build directories, although the actual buildsystem > they create is identical (assuming using all Makefile based or > all Ninja based 'extra generators') > > * Make it possible to write a plugin for the editors/IDEs such as sublime > which consumes the metadata file and invokes the build using whatever > buildsystem the user already has a build directory for, instead of > writing an 'extra generator' and maintaining it in the cmake repo. > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9004 > > * Make it possible for editors/IDEs to allow specifying the configuration > at build-time, where the IDE has that feature, and where a multi-config > generator is available. That is, QtCreator provides user-interface for > choosing debug/release config to build. Currently it can't offer that > when using cmake, because it only allows the use of Makefile or Ninja > generators, in order to make use of the C::B file. QtCreator should be > able to use the Xcode or Visual Studio generators, generate the metadata > file(s), and invoke `cmake --build . --config ${CONFIG}` as > appropriate. Eclipse, Sublime and other editors have similar abilities > to invoke config-specific builds after generation. > > * Provide a list of 'build targets', which can be listed and invoked in > IDE/editor user interface. Build targets for all linked binaries > and utilties are provided. The tooling is expected to perform filtering > on the target types to show only executables and utilities for > execution, for example. > > * Provide a list of source files per target per type of source file, eg > object sources, header files, generated files, files excluded from the > active configuration/platform/compiler, non-compiled files. > > * Make it more easy for an IDE to support actions such as 'remove file > from the project', which requires removing it from the CMakeLists.txt > at the appropriate place, and 'add new file/class to target', which > involves adding code to the CMakeLists.txt file at the appropriate > place. Most likely the easiest way to do the latter is using the > target_sources() command, and to support the former, the location of > the declaration of the target, and all target_sources() calls would > need to b
[cmake-developers] [CMake 0015446]: In verbose mode, display env vars that were explicitly set for each test
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15446 == Reported By:Zach Mullen Assigned To: == Project:CMake Issue ID: 15446 Category: CTest Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2015-03-13 17:29 EDT Last Modified: 2015-03-13 17:29 EDT == Summary:In verbose mode, display env vars that were explicitly set for each test Description: We use set_property with the ENVIRONMENT property for many of our tests to control their runtime behavior. When running in verbose mode we see the full command line that is executed, but not the environment variables that were explicitly set for the test invocation. It would be nice to include those. == Issue History Date ModifiedUsername FieldChange == 2015-03-13 17:29 Zach MullenNew 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 0015445]: Interface in Russian Language
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15445 == Reported By:abductor Assigned To: == Project:CMake Issue ID: 15445 Category: CMake Reproducibility:N/A Severity: major Priority: low Status: new == Date Submitted: 2015-03-13 14:07 EDT Last Modified: 2015-03-13 14:07 EDT == Summary:Interface in Russian Language Description: I use CMake 2.8.10.2. And I will use 3.2.1 on next week. Cool, what file name in path maybe in Russian language in 3.2.1. I wont help to translate interface and message in russian language. == Issue History Date ModifiedUsername FieldChange == 2015-03-13 14:07 abductor 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 0015444]: include_directories is case insensitive usually, but is case sensitive in files inside subfolders
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15444 == Reported By:alean79 Assigned To: == Project:CMake Issue ID: 15444 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-03-13 13:40 EDT Last Modified: 2015-03-13 13:40 EDT == Summary:include_directories is case insensitive usually, but is case sensitive in files inside subfolders Description: I have a project that was developed in Windows environment, so the #include sentences was developed in case insensitive way (there are a LOT of differences between the name of the .hpp included, and the real name of the .hpp file). I imported that project in a Linux environment, and configured cmake with the following clause: include_directories( SYSTEM ${PROJECT_SOURCE_DIR}/inc) Inside the "inc" folder there are .hpp files, but there are subfolders with aditional .hpp files. In my code, the .hpp files that are in the "inc" folder are recognized correctly, beside the case problems. But the files in the subfolders are NOT recognized if there are case differences. Example: ${PROJECT_SOURCE_DIR} | |-- inc | |-- vpp => subfolder || ||-- vpp.hpp => header file | |-- flags.hpp => header file If I include the second header file with the following sentence, the file is recognized correctly: #include But, if I include the first header file with the following sentence, the file is NOT found: #include == Issue History Date ModifiedUsername FieldChange == 2015-03-13 13:40 alean79New Issue 2015-03-13 13:40 alean79File Added: CMakeLists.txt == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support
These sounds like easy changes, but I probably won't be able to update and test it until the middle of next week. Geoffrey Viola SOFTWARE ENGINEER asirobots.com -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Thursday, March 12, 2015 2:18 PM To: Geoffrey Viola Cc: cmake-developers@cmake.org Subject: Re: FW: FW: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support On 03/11/2015 01:39 PM, Geoffrey Viola wrote: > Attached is a patch with the recommended changes Thanks! The basic toolchain initialization is pretty close. Here are more comments. In Modules/Platform/GHS-MULTI-Initialize.cmake: > +#Setup consistent compiler executables > +find_program(CMAKE_GENERATOR_CC ccarm PATHS ${GHS_COMP_ROOT}) > +find_program(CMAKE_GENERATOR_CXX cxarm PATHS ${GHS_COMP_ROOT}) This should not be needed at all. The CMAKE_GENERATOR_* variables are just hints to the compiler detection logic. Since this generator hard-codes the compiler setting in C++ the logic that uses these variables is never executed anyway. > +string(REGEX MATCH "(comp_)([0-9]+)" CMAKE_SYSTEM_VERSION > +"${CMAKE_MAKE_PROGRAM}") string(REPLACE "comp_" "" > +CMAKE_SYSTEM_VERSION "${CMAKE_SYSTEM_VERSION}") EnableLanguage should be able to set CMAKE_SYSTEM_VERSION too now that it has code to find the comp root. > +mark_as_advanced(CMAKE_MAKE_PROGRAM) This should not be needed. > +include(Platform/WindowsPaths) This should move to Modules/Platform/GHS-MULTI.cmake In EnableLanguage: > + mf->AddDefinition("CMAKE_MAKE_PROGRAM", > +std::string(ghsCompRootStart + > + "gbuild.exe").c_str()); The VS and Xcode generators no longer put this in the cache. Take a look at how the Xcode generator now does this with cmGlobalXCodeGenerator::FindMakeProgram cmGlobalXCodeGenerator::GetXcodeBuildCommand cmGlobalXCodeGenerator::FindXcodeBuildCommand and its call to SelectMakeProgram in GenerateBuildCommand: this->SelectMakeProgram(makeProgram, this->GetXcodeBuildCommand()) Together this all allows the generator to compute the proper build tool without exposing any settings to the user. > + mf->AddDefinition("CMAKE_C_COMPILER_ID", "GhsMultiArmC"); [snip] > + mf->AddDefinition("CMAKE_CXX_COMPILER_ID", "GhsMultiArmCXX"); Instead of "GhsMultiArm*" these should be just "GHS", to be consistent with "Modules/Compiler/GHS-DetermineCompiler.cmake". - Please also look at modifying the Help/ directory to document the new generator. You'll need at least to create/update: Help/manual/cmake-generators.7.rst Help/generator/Green Hills MULTI.rst Help/variable/CMAKE_MAKE_PROGRAM.rst where the change to the last one depends on the above updates. Thanks, -Brad 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. -- 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] Generating buildsystem metadata from CMake
On 03/11/2015 11:10 AM, Stephen Kelly wrote: I'm starting to gather requirements and make sure the feature is well designed to satisfy the needs we're already aware of, and fits with the features CMake currently has. Source file groups (as in defined by source_group()) and target folders (as in the FOLDER target property) may be of interest to IDEs to layout target and source file hierarchies. Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating buildsystem metadata from CMake
On 03/11/2015 11:10 AM, Stephen Kelly wrote: > Hi, > > Following from the thread here: > > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12394 > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12650 > The discussion in that thread is causing people confusion (eg regarding an obsolete approach to config and CMAKE_BUILD_TYPE). Please discontinue the discussion there. My branch is the way forward. I extended my branch to contain not only test and documentation but also an implementation and a generated file from my computer, so that you can read it/try it and give feedback. Obviously the branch needs to be broken up into multiple commits, but that something to do when this is not a prototype anymore. We are still in a design discussion. I pushed the implementation only because I know you guys won't discuss the design of the feature on its own and you want to have an implementation asap. However, this is still a design discussion, and all of the questions in my previous mail are still valid. 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] RFC: CMake precompiled header support and custom compiler based implementation
On Wed, Mar 4, 2015 at 8:53 PM, Brad King wrote: > On 03/03/2015 07:43 AM, Adam Strzelecki wrote: > > On 03/01/2015 08:02 PM, Ben Boeckel wrote: > >> On 02/28/2015 11:59 AM, Adam Strzelecki wrote: > >> target_precompiled_header( ) > >> > >> target_precompiled_header( > SHARED > >> > ) > >> Could we rename this? Currently target_* functions are all related to > >> usage requirements and these are not usage requirements. > > > > Honestly I don't understand your request. What would be then the name > > that better represents what the function does. > > Currently the target_* commands are: > > target_compile_definitions > target_compile_features > target_compile_options > target_include_directories > target_link_libraries > target_sources > > They all have the general signature > > target_command( [options] [ ...]...) > > where is INTERFACE, PUBLIC, or PRIVATE and affects whether the > settings apply to sources in the target itself and/or its dependents. > The proposed target_precompiled_header signature does not fit into > this layout. Either a different command name is needed or one needs > to define the command signature and semantics to fit the above layout. > Do PCHs fit into usage requirements in any way? > That would be nice, right? I pushed some work to https://github.com/purpleKarrot/CMake/commits/pch Expect it to be incomplet and incorrekt. It certainly needs a couple of iterations, but the direction should be clear: add_library(foo foo.c) target_include_directories(foo PUBLIC include) target_precompile_headers(foo PUBLIC foo.h) add_library(bar INTERFACE) target_include_directories(bar INTERFACE include) target_precompile_headers(bar INTERFACE bar.h) add_executable(foobar foobar.c) target_link_libraries(foobar foo bar) There is a new command called "target_precompile_headers". This name is chosen carefully. * It says "precompile headers", not "precompiled header". This command is used to set a list of headers "to precompile". It is not used to specify a single prebuilt file. * It has a "target_" prefix, and the expectations about usage requirements should be satisfied. Things to keep in mind: * We probably want to precompile headers based on configuration. * For generators that support it (Makefile + Ninja), we want to precompile headers based on the compile language. * We probably want to enable/disable the use of PCH globally, on a per-target-level, and on a per-source-level. > In meantime https://github.com/nanoant/CMakePCHCompiler is just an implementation that "emulates" desired behavior using many tricks. But I don't want this to be a part of CMake, but instead I want this to be handled natively adding some extra variables: Good. That means we are on the same page. I was a little confused when I first saw your approach. :-) cheers, Daniel -- 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] RFC: Helper macros for writing Find modules
For the extra-cmake-modules package, I wrote some macros to help with writing component-based Find modules, which are non-trivial to get right. The documentation for them can be found here: http://api.kde.org/ecm/module/ECMFindModuleHelpers.html I've found them incredibly useful in writing classic Find modules, where you just want to find a bunch of libraries and their associated headers, but you also need to account for the dependencies between those libraries. The interface is a little unusual: you have to set up some information- providing variables before calling the macros to describe the information for each component. As an example, see http://quickgit.kde.org/?p=extra-cmake-modules.git&a=blob&h=c5a56c1635d03acdaf5ccd780b9a358d6f6655fd&hb=4f81d1a92e4ccc2ce7b33d2860397a526b1a4d2f&f=find-modules%2FFindWayland.cmake (which I would also submit for inclusion to CMake if this is accepted). Would this be something that might be included in CMake? I have some ideas about how to extend it to be able to account for debug vs release libraries as well (roughly following a simplified version of the pattern of the FindQt4 module). Alex -- 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 0015443]: Unable to use target_compile_features with MinGW-w64
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15443 == Reported By:David Demelier Assigned To: == Project:CMake Issue ID: 15443 Category: CMake Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2015-03-13 04:42 EDT Last Modified: 2015-03-13 04:42 EDT == Summary:Unable to use target_compile_features with MinGW-w64 Description: The following CMakeLists.txt generates an error on MinGW-w64: cmake_minimum_required(VERSION 3.2) project(test) add_executable(main main.cpp) target_compile_features( main PRIVATE cxx_constexpr ) This is the error: CMake Error at CMakeLists.txt:6 (target_compile_features): target_compile_features no known features for CXX compiler "GNU" version 4.9.2. Steps to Reproduce: 1. Try to use target_compile_features with MinGW-w64 Additional Information: It seems that Modules/Compiler/GNU-CXX.cmake has useless UNIX conditionals: Changing lines 47 and 50 to the following fix the problem: set(_result 0) if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.8) _get_gcc_features(${CMAKE_CXX14_STANDARD_COMPILE_OPTION} CMAKE_CXX14_COMPILE_FEATURES) endif() if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.4) if (_result EQUAL 0) _get_gcc_features(${CMAKE_CXX11_STANDARD_COMPILE_OPTION} CMAKE_CXX11_COMPILE_FEATURES) endif() if (_result EQUAL 0) _get_gcc_features(${CMAKE_CXX98_STANDARD_COMPILE_OPTION} CMAKE_CXX98_COMPILE_FEATURES) endif() endif() Please note that MinGW-w64 fully supports C++11 and C++14. == Issue History Date ModifiedUsername FieldChange == 2015-03-13 04:42 David Demelier 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 0015442]: Test 124 fails, space before colon in check_file_match_expected_relocation_path
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15442 == Reported By:Daniel TISCHER Assigned To: == Project:CMake Issue ID: 15442 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-03-13 03:18 EDT Last Modified: 2015-03-13 03:18 EDT == Summary:Test 124 fails, space before colon in check_file_match_expected_relocation_path Description: The following tests FAILED: 124 - CPackComponentsForAll-RPM-IgnoreGroup (Failed) 124: error: 124: '/home/quickbuild/workspace/root/packages/cmake/BUILD/cmake-3.2.1/build/Tests/CPackComponentsForAll/buildRPM-IgnoreGroup/MyLib-1.0.2-Linux-headers.rpm' 124: rpm package relocation path does not match expected value - regex 124: 'Relocations : /usr/foo/bar /usr/foo/bar/include'; RPM output: 'Name : 124: mylib-headers Relocations: /usr/foo/bar /usr/foo/bar/include [root@jawas ~]# rpm -qpi /home/quickbuild/workspace/root/packages/cmake/BUILD/cmake-3.2.1/build/Tests/CPackComponentsForAll/buildRPM-IgnoreGroup/MyLib-1.0.2-Linux-headers.rpm Name: mylib-headersRelocations: /usr/foo/bar /usr/foo/bar/include Version : 1.0.2 Vendor: CMake.org Release : 1 Build Date: Thu 12 Mar 2015 09:36:37 PM CET --> there is no space between "Relocations" and colon ":" Steps to Reproduce: run tests Additional Information: RunCPackVerifyResult.cmake lines 167, 174, 180, 186 set(check_file_match_expected_relocation_path "Relocations : --^ [root@jawas ~]# rpm --version RPM version 4.8.0 == Issue History Date ModifiedUsername FieldChange == 2015-03-13 03:18 Daniel TISCHER 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