[cmake-developers] [CMake 0015531]: InstallRequiredSystemLibraries misses MBCS MFC libraries
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15531
==
Reported By:Bjoern Thiel
Assigned To:
==
Project:CMake
Issue ID: 15531
Category: Modules
Reproducibility:always
Severity: crash
Priority: high
Status: new
==
Date Submitted: 2015-04-24 05:12 EDT
Last Modified: 2015-04-24 05:12 EDT
==
Summary:InstallRequiredSystemLibraries misses MBCS MFC
libraries
Description:
if(${v} LESS 12 OR EXISTS ${MSVC${v}_MFC_DIR}/mfc${v}0d.dll)
may be false for version = 12 as ${MSVC${v}_MFC_DIR} is not always set
correctly at that time.
Additional Information:
I patched it replacing the
if(mbcs)
with
if(${v} LESS 12 OR EXISTS ${MSVC${v}_MFC_DIR}/mfc${v}0d.dll)
and
if(${v} LESS 12 OR EXISTS ${MSVC${v}_MFC_DIR}/mfc${v}0.dll)
and erasing the set(mbcs ... stuff.
==
Issue History
Date ModifiedUsername FieldChange
==
2015-04-24 05:12 Bjoern Thiel 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] [CMake] cmake 3.1.1 does not generate x64 profile for visual studio
We really shouldn't have removed the explicit mention of the Win64 suffixed generator names in the list of generators in --help ouput... That was a mistake. We should put it back. On Fri, Apr 24, 2015 at 5:29 AM, Xi Shen davidshe...@gmail.com wrote: Ah~, so it's a hidden feature? OK, I will give a try. Thanks, David On Fri, 24 Apr 2015 16:38 J Decker d3c...@gmail.com wrote: there's a 64 bit generator... used to be a separate generator visual studio 12 2013 Win64 but it doesn't show in the list of generators now... On Thu, Apr 23, 2015 at 11:27 PM, Xi Shen davidshe...@gmail.com wrote: Hi, I am using cmake 3.1.1 on my Windows 7 64bit system. I have Visual Studio 2013 installed. The project I created with cmake works and can build with msbuild. But it only build the x86 version. If I try: msbuild /property:Platform=x64 myproj.vcproj I got error says that the x64 profile does not exist. I have to open the project file and create the x64 profile by myself. Is there any way to let cmake generate the x64 profile? Thanks, David -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -- 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] cmake 3.1.1 does not generate x64 profile for visual studio
Excellent. Thanks for the pointer... I had not seen that recent commit. Seems we had a shared this should be explained better so we don't get so much email about it brain wave pattern. Happy Friday, D On Fri, Apr 24, 2015 at 9:04 AM, Nils Gladitz nilsglad...@gmail.com wrote: On 04/24/2015 02:40 PM, Nils Gladitz wrote: Maybe instead of listing all known permutations in --help each generator (where the option is supported) could be listed with a well known subset of supported target platforms. Never mind ... apparently Brad already did that (except with generators suffixes rather than -A): http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=1e3843373f8e0dfd550809ec034d535d31276b6b 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] [CMake] cmake 3.1.1 does not generate x64 profile for visual studio
On 04/24/2015 02:22 PM, David Cole via cmake-developers wrote: We really shouldn't have removed the explicit mention of the Win64 suffixed generator names in the list of generators in --help ouput... That was a mistake. We should put it back. As I understand it the generator suffixes aren't the preferred method to pick the architecture anymore. You can now use the -A x64 option with the visual studio generators instead. Also it looks like the supported target platforms aren't a fixed list that can be easily enumerated (e.g. WinCE-SDK [1]) Maybe instead of listing all known permutations in --help each generator (where the option is supported) could be listed with a well known subset of supported target platforms. Nils [1] http://www.cmake.org/cmake/help/v3.2/generator/Visual%20Studio%2011%202012.html -- 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 0015534]: find_package(Threads) needs C
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15534 == Reported By:James Bigler Assigned To: == Project:CMake Issue ID: 15534 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-04-24 18:28 EDT Last Modified: 2015-04-24 18:28 EDT == Summary:find_package(Threads) needs C Description: If you specify your project as CXX, and you use find_package(Threads) you will get a failure, because the test programs use .c files.: Steps to Reproduce: cmake_minimum_required(VERSION 3.2) project(Test CXX) find_package(Threads REQUIRED) == Issue History Date ModifiedUsername FieldChange == 2015-04-24 18:28 James Bigler 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] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 22/04/15 23:46, Domen Vrankar a écrit : Hi, I just installed a virtual machine running Debian 7.8.0, and everything worked like a charm from the first run. I did that in the two following way: - sourced my branch https://github.com/raffienficiaud/CMake/tree/cpack_deb_refactoring - I also applied the cherry-picked from that branch onto your merge to next (8e0ecf91b3d50a0e69a00db52d1d79ca91afecc4). The only packages I installed from a default installation are vim, build-essential, git, gcc-4.7, cmake, qtcreator, clang. Putting the quotes in that case should be safer. So I cannot reproduce the error on my side. The log would be helpful. Odd... I'm not certain what the difference between our virtual machines is then. As far as I can remember I only additionally installed gcc and cmake. Maybe some updates... Attached are the generated files, verbose output and dpkg-deb -I output for application package. Thanks, Domen Hi, Would you please add set( CPACK_DEBIAN_PACKAGE_DEBUG ON) to the file MyLibCPackConfig-splitted-components-depend2.cmake.in so that we also have the debug logs? BTW, I do not know what CPackDEB.cmake you are running. Is it pushed somehow? Thanks, Best, Raffi -- 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 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 22/04/15 08:01, Domen Vrankar a écrit : 2015-04-21 23:38 GMT+02:00 Raffi Enficiaud raffi.enfici...@mines-paris.org: Le 21/04/15 23:01, Domen Vrankar a écrit : There are a few other things to change though. Take a look at CPackRPM man page: http://www.cmake.org/cmake/help/v3.2/module/CPackRPM.html?highlight=cpack%20rpm There is an explanation at the top that component variables override non component variables and then each non component and component variable is explained at the same time - without this the man page will get even longer as it already is without a good reason. Please change the way you wrote the documentation for your component variables. Also put the text: # The value of `CPACK_DEBIAN_COMP_PACKAGE_DEPENDS` can be set to an empty string # to enable the automatic discovery of dependencies without inheriting from # the default value of :variable:`CPACK_DEBIAN_PACKAGE_DEPENDS`. inside a Note so that it will be more visible. Thanks, Domen Hi, Please find attached a patch for the reworked documentation. I tried to make the doc more consistent with the CPackRPM (doc right after the variable declaration and options afterwards). I also put links for the variables and changed the formatting a bit. There are a couple of things though: - the variable CPACK_PACKAGE_CONTACT does not exist anywhere in the code - right now, the CPACK_COMPONENT_COMP_DESCRIPTION is used as an equivalent to the CPACK_DEBIAN_PACKAGE_DESCRIPTION per component. If I follow the RPM conventions, those would be called CPACK_DEBIAN_COMP_PACKAGE_DESCRIPTION, which I find also better. However, in that case, should it default to CPACK_COMPONENT_COMP_DESCRIPTION or to CPACK_DEBIAN_PACKAGE_DESCRIPTION? In fact CPACK_COMPONENT_COMP_DESCRIPTION and CPACK_DEBIAN_COMP_PACKAGE_DESCRIPTION would have the same purpose and I think that it will not be obvious for the user to cope with all those variables. Best, Raffi From 870d8e9e1041daf46a89f061eacd36690286687f Mon Sep 17 00:00:00 2001 From: Raffi Enficiaud raffi.enfici...@mines-paris.org Date: Fri, 24 Apr 2015 17:03:47 +0200 Subject: [PATCH] CPackDeb: reworked documentation --- Modules/CPackDeb.cmake | 224 + 1 file changed, 134 insertions(+), 90 deletions(-) diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake index 07cd1bc..869941c 100644 --- a/Modules/CPackDeb.cmake +++ b/Modules/CPackDeb.cmake @@ -15,214 +15,258 @@ # the build system. # # CPackDeb has specific features which are controlled by the specifics -# CPACK_DEBIAN_XXX variables.You'll find a detailed usage on the wiki: -# http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#DEB_.28UNIX_only.29 +# :code:`CPACK_DEBIAN_XXX` variables. # +# :code:`CPACK_DEBIAN_COMP_` variables may be used in order to have +# **component** specific values. Note however that COMP refers +# to the **grouping name**. This may be either a component name or a +# component GROUP name. +# +# You'll find a detailed usage on the wiki: +# http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#DEB_.28UNIX_only.29 . # However as a handy reminder here comes the list of specific variables: # +# # .. variable:: CPACK_DEBIAN_PACKAGE_NAME # +# The debian package summary +# # * Mandatory : YES -# * Default : CPACK_PACKAGE_NAME (lower case) +# * Default : :variable:`CPACK_PACKAGE_NAME` (lower case) # -# The debian package summary # # .. variable:: CPACK_DEBIAN_PACKAGE_VERSION # +# The debian package version +# # * Mandatory : YES -# * Default : CPACK_PACKAGE_VERSION +# * Default : :variable:`CPACK_PACKAGE_VERSION` # -# The debian package version # # .. variable:: CPACK_DEBIAN_PACKAGE_ARCHITECTURE # +# The debian package architecture +# # * Mandatory : YES -# * Default : Output of dpkg --print-architecture (or i386 if dpkg is not found) +# * Default : Output of :code:`dpkg --print-architecture` (or :code:`i386` +#if :code:`dpkg` is not found) # -# The debian package architecture # # .. variable:: CPACK_DEBIAN_PACKAGE_DEPENDS +# CPACK_DEBIAN_COMP_PACKAGE_DEPENDS +# +# May be used to set deb dependencies. # # * Mandatory : NO -# * Default : - +# * Default : # -# May be used to set deb dependencies. +#- An empty string for non-component based installations +#- :variable:`CPACK_DEBIAN_PACKAGE_DEPENDS` for component-based +# installations. # -# .. variable:: CPACK_DEBIAN_COMP_PACKAGE_DEPENDS +# .. note:: # -# * Mandatory : NO -# * Default : :variable:`CPACK_DEBIAN_PACKAGE_DEPENDS` +#If :variable:`CPACK_DEBIAN_PACKAGE_SHLIBDEPS` or +#more specifically :variable:`CPACK_DEBIAN_COMP_PACKAGE_SHLIBDEPS` is +#set for this component, the discovered dependencies will be appended +#to :variable:`CPACK_DEBIAN_COMP_PACKAGE_DEPENDS` intead of +#:variable:`CPACK_DEBIAN_PACKAGE_DEPENDS`. If +#:variable:`CPACK_DEBIAN_COMP_PACKAGE_DEPENDS` is an empty string, only +#
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 22/04/15 08:01, Domen Vrankar a écrit :
2015-04-21 23:38 GMT+02:00 Raffi Enficiaud raffi.enfici...@mines-paris.org:
Le 21/04/15 23:01, Domen Vrankar a écrit :
Hi,
I pushed your first patch to next (I've split it into two separate
commits and made some minor cleanup changes):
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=8e0ecf9
Please find attached my last patch that allows the settings of the
dependencies per component.
I haven't finished reviewing the rest of the patches however I've
noticed that you omit quotes when setting or comparing variables.
Ok. I might help in the future if you point me on a specific line and
explain me the mistake.
Almost every line in your cmake scripts that uses set, if, string or
other commands (see the explanation below).
I wouldn't be bothering you with that and fix it myself if the test
wouldn't be failing and some other changes needed to be done.
I've also noticed that the last test in last commit is succeeding on
Ubuntu 15.04 but failing on Debian 7.8.0.
It first fails with a cryptic error (string FIND requires X variables
as input message...) on this line:
string(FIND ${dpkg_depends} lib index_libwhatever)
and after I put quotes arround ${dpkg_depends} it returns an error
that the value is an empty string.
It might help if you send me the test log file of the run.
I'll send you the data in the afternoon.
On the other
hand, I do not understand why it would be an error if ${dpkg_depends} is
an empty string. (I should still be able to find from an empty string,
shouldn't I?)
If you take a look at the code it searches for lib inside
${dpkg_depends} and then the next line checks if it found the content
and prints out an error instead (so the test fails) - that is the
expected way of your test failing.
On the other hand since the value of ${dpkg_depends} is an empty
string that value doesn't contain a value... So without quotes it is
the same as if that variable would not even exist in the above string
command (there is no empty string - the variable gets substituted by
the content of that variable so it's the same as writing nothing) -
and test failing like that is probably not what you intended.
The other reason is that set(some_var some_value other_value) creates
a list and set(some_var some_value) creates a string (list with one
value) and set(var foo bar) set(other_var ${var}) creates an array
from string... Also using set(some_var) is cryptic - it's hard to know
if you meant unset(some_var) or set(some_var )...
That is why I mentioned that you aren't using any quotes most of the
time while using variables.
Hi,
I am having a look now at the changes you made on the first patch (say
75b0e1679c39ca824a4c49d9e1a2ae2b5f04ae06), file
RunCPackComponentsDEB/RunCPackVerifyResult-components-lintian-dpkgdeb-checks.cmake
Instead of finding lintian and dpkg-deb in the check file
find_program(LINTIAN_EXECUTABLE lintian)
find_program(DPKGDEB_EXECUTABLE dpkg-deb)
why not returning the string NOTFOUND in eg. the functions run_lintian
lintian_output, like this:
set(${lintian_output} NOTFOUND PARENT_SCOPE)
If I understand correctly this should evaluate to false in an if() and
we should be able to make the distinction with an empty string. On the
other hand, we can add a variable that may return ok, notfound or
error.
What are the best practices there?
Best,
Raffi
--
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 0015533]: CMake documentation for CTEST_USE_LAUNCHERS wrongly states it only works with Makefile generator: it also works with Ninja
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15533 == Reported By:trsystran Assigned To: == Project:CMake Issue ID: 15533 Category: CMake Reproducibility:N/A Severity: text Priority: normal Status: new == Date Submitted: 2015-04-24 12:08 EDT Last Modified: 2015-04-24 12:08 EDT == Summary:CMake documentation for CTEST_USE_LAUNCHERS wrongly states it only works with Makefile generator: it also works with Ninja Description: http://www.cmake.org/cmake/help/v3.0/module/CTest.html ... http://www.cmake.org/cmake/help/v3.2/module/CTest.html (Currently the CTEST_USE_LAUNCHERS option is ignored on non-Makefile generators.) But since https://github.com/Kitware/CMake/commit/965358fcf64cf1a3693bcdd66f723729e0614ef6 Ninja generator is also supported. According to github it should work for cmake = 2.8.11. This should be reflected in the documentation. (There maybe other locations with this incorrect statement...) == Issue History Date ModifiedUsername FieldChange == 2015-04-24 12:08 trsystran 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] Generator Expressions in CPack (Module) variables
Hello, would it be possible to add generator expression support to CPack so that I can use $CONFIG within CPACK_PACKAGE_FILE_NAME? I'm using the CPack module from within my CMakeLists.txt. I'm trying to generate unique file names per architecture and configuration but multi config generators like Xcode make this harder than expected. Before digging into that topic I'd like to know if this would be a dead end. Thanks, Gregor PS: Currently I'm appending a random 5 character string. -- 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] Generator Expressions in CPack (Module) variables
On 24.04.2015 20:55, Gregor Jasny wrote: Hello, would it be possible to add generator expression support to CPack so that I can use $CONFIG within CPACK_PACKAGE_FILE_NAME? I'm using the CPack module from within my CMakeLists.txt. I'm trying to generate unique file names per architecture and configuration but multi config generators like Xcode make this harder than expected. Before digging into that topic I'd like to know if this would be a dead end. You should be able to do this without generator expressions and just CPACK_PROJECT_CONFIG_FILE [1] and CPACK_BUILD_CONFIG [2]. If you really do require/want generator expressions you should be able to combine that with file(GENERATE) and include(). Nils [1] http://www.cmake.org/cmake/help/v3.2/module/CPack.html#variable:CPACK_PROJECT_CONFIG_FILE [2] Set by cpack to the configuration being packaged (e.g. Debug, Release, ...) [3] http://www.cmake.org/cmake/help/v3.2/command/file.html -- 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 --help-policy CMP0057 MAIN_DEPENDENCY
This new policy breaks a long standing feature of FindCUDA. Basically I could add the MAIN_DEPENDENCY to all CUDA files built. If the same CUDA file was used in multiple custom commands it would attach the build rule to the first command, and leave the remaining ones as phantom .rule files in the project. I don't want to turn off the MAIN_DEPENDENCY feature, so should I push/pop the policy in FindCUDA.cmake? James -- 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
