Re: [cmake-developers] Making kwsys a proper library
On 08/14/2015 08:11 AM, Brad King wrote: On 08/13/2015 10:36 PM, Orion Poplawski wrote: There is concern in Fedora that the kwsys code has become too large to be an acceptable copylib. However, as cmake is constructed at the moment it would be a huge undertaking for the Fedora packagers (mostly me) to remove it downstream. So I'm asking if there is any support upstream for making kwsys a proper library? KWSys is a copylib by design. Each project using it configures the library with a different namespace/prefix, can enable different subsets of the library, and can choose some behavior toggles. Some projects maintain local patches to their copy of KWSys that are good enough for themselves but not for upstream. KWSys cannot be shared by multiple such clients as a single library and should *never be distributed as a packaged binary*. If each of Kitware's projects using KWSys maintained the code separately under different hard-coded names (cmsys, vtksys, itksys, etc.) then no one would be expecting it to be a separate library. The shared KWSys source helps share maintenance among these projects while still each getting a custom library that never conflicts with the others. -Brad Yeah, it's very clear that that is how it is at the moment. I guess I'm asking if that is an appropriate design for a decent size chunk of code. What makes the kwsys code special in a way that makes creating a shared library inappropriate? There may indeed be valid reasons, but I just don't know them. You mentioned behavior toggles - that seems like a likely candidate - could you give a bit more detail? Thank you very much for your time and response. Really. PS - I don't want to come off like a jerk asking this, although that seems almost inevitable with email. I'm also a bit frustrated from my experiences as a member of the Fedora Packaging Committee as it seems with the rise of git submodules it's becoming easier and easier for projects to share code by bundling rather than via shared libraries. This seems to negate all of the positives of shared libraries (reduced code and memory usage, delivery of bug/security fixes via a single update, etc) for the convenience of not having to deal with maintaining a stable API/ABI. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- 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] Making kwsys a proper library
On 08/14/2015 08:27 AM, Ben Boeckel wrote: On Thu, Aug 13, 2015 at 20:36:55 -0600, Orion Poplawski wrote: There is concern in Fedora that the kwsys code has become too large to be an acceptable copylib. However, as cmake is constructed at the moment it would be a huge undertaking for the Fedora packagers (mostly me) to remove it downstream. So I'm asking if there is any support upstream for making kwsys a proper library? Not right now. The thing is that each library which uses it mangles all of the symbols individually by configuring the source files, so without rewriting how kwsys is *used* in all of its downstream projects (cmake, VTK, ITK, and likely others), kwsys would likely have to be shipped as source anyways. That's certainly what I've found at the moment. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- 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 0015697]: CUDA separable compilation intermediate file doesn't get created
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15697 == Reported By:Dominic Meiser Assigned To: == Project:CMake Issue ID: 15697 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-08-14 16:37 EDT Last Modified: 2015-08-14 16:37 EDT == Summary:CUDA separable compilation intermediate file doesn't get created Description: When I compile with CUDA_SEPARABLE_COMPILATION=TRUE the custom command for the generation of the intermediate_link.obj does not get triggered. When I change line 1590 in FindCUDA.cmake (master version from earlier today) to `set(do_obj_build_rule TRUE)` the custom command does run and compilation succeeds. I don't see the bug here. I'm seeing this behavior with cmake 3.2.2 and master revision 17ecfd8210. Steps to Reproduce: configure a cuda library target with CUDA_SEPARABLE_COMPILATION=TRUE and build. Additional Information: This is with cuda toolkit 7.0 == Issue History Date ModifiedUsername FieldChange == 2015-08-14 16:37 Dominic Meiser 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] Recursion in OUTPUT_NAME genex (was: Generator expressions for output directory)
Here is the patch for OUTPUT_NAME genex recursion issue. I took the decision to send you the patch using mutable map, in order to reduce the number of changes and focus on the actual fix. Cheers! -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Friday, August 14, 2015 3:47 PM To: Stephen Kelly Cc: Robert Goulet ; cmake-developers@cmake.org Subject: Re: Recursion in OUTPUT_NAME genex (was: Generator expressions for output directory) Steve, Robert Goulet (in Cc) is working on detecting recursion in GetOutputName. Recent refactoring moved this from cmTarget to cmGeneratorTarget, leading to this question: On 08/14/2015 03:28 PM, Robert Goulet wrote: > I got a patch working for the OUTPUT_NAME genex recursion problem, > however I'm not sure where to store the map. The function > GetOutputName is const, so I can't change the map if it's stored in > the cmGeneratorTarget class, unless I remove a bunch of const from > many functions, which is not ideal. Any suggestion as to where I > should store the map? Should we introduce an "internal" pointer like > in cmTarget class? We'd like to store a map for this information much like cmTarget does for GetOutputInfo. Should we just make GetOutputName non-const, store a mutable map (since it is for memoization), add an "internal" object, or something else? Thanks, -Brad output-name-genex-recursion-fix.patch Description: output-name-genex-recursion-fix.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
Re: [cmake-developers] Recursion in OUTPUT_NAME genex (was: Generator expressions for output directory)
You made me realize that other members of that class are simply using mutable keyword. This would make the change less risky and smaller in scope. Perhaps it would be best to just follow this line and keep further refactoring for a different patch? -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Friday, August 14, 2015 3:47 PM To: Stephen Kelly Cc: Robert Goulet ; cmake-developers@cmake.org Subject: Re: Recursion in OUTPUT_NAME genex (was: Generator expressions for output directory) Steve, Robert Goulet (in Cc) is working on detecting recursion in GetOutputName. Recent refactoring moved this from cmTarget to cmGeneratorTarget, leading to this question: On 08/14/2015 03:28 PM, Robert Goulet wrote: > I got a patch working for the OUTPUT_NAME genex recursion problem, > however I'm not sure where to store the map. The function > GetOutputName is const, so I can't change the map if it's stored in > the cmGeneratorTarget class, unless I remove a bunch of const from > many functions, which is not ideal. Any suggestion as to where I > should store the map? Should we introduce an "internal" pointer like > in cmTarget class? We'd like to store a map for this information much like cmTarget does for GetOutputInfo. Should we just make GetOutputName non-const, store a mutable map (since it is for memoization), add an "internal" object, or something else? 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] Recursion in OUTPUT_NAME genex (was: Generator expressions for output directory)
Steve, Robert Goulet (in Cc) is working on detecting recursion in GetOutputName. Recent refactoring moved this from cmTarget to cmGeneratorTarget, leading to this question: On 08/14/2015 03:28 PM, Robert Goulet wrote: > I got a patch working for the OUTPUT_NAME genex recursion problem, > however I'm not sure where to store the map. The function GetOutputName > is const, so I can't change the map if it's stored in the > cmGeneratorTarget class, unless I remove a bunch of const from many > functions, which is not ideal. Any suggestion as to where I should > store the map? Should we introduce an "internal" pointer like in > cmTarget class? We'd like to store a map for this information much like cmTarget does for GetOutputInfo. Should we just make GetOutputName non-const, store a mutable map (since it is for memoization), add an "internal" object, or something else? 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] Generator expressions for output directory
Hi Brad, I got a patch working for the OUTPUT_NAME genex recursion problem, however I'm not sure where to store the map. The function GetOutputName is const, so I can't change the map if it's stored in the cmGeneratorTarget class, unless I remove a bunch of const from many functions, which is not ideal. Any suggestion as to where I should store the map? Should we introduce an "internal" pointer like in cmTarget class? Thanks! -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Thursday, August 13, 2015 10:33 AM To: Robert Goulet Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] Generator expressions for output directory On 08/11/2015 01:51 PM, Robert Goulet wrote: > Here's the updated patch for OUTPUT_DIRECTORY supporting genex. Thanks. Applied with a few tweaks: cmTarget: Detect and diagnose recursion in GetOutputInfo http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e36a05fd Add generator expression support to OUTPUT_DIRECTORY target properties http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d25819bc -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] Making kwsys a proper library
On Thu, Aug 13, 2015 at 20:36:55 -0600, Orion Poplawski wrote: > There is concern in Fedora that the kwsys code has become too large to > be an acceptable copylib. However, as cmake is constructed at the > moment it would be a huge undertaking for the Fedora packagers (mostly > me) to remove it downstream. So I'm asking if there is any support > upstream for making kwsys a proper library? Not right now. The thing is that each library which uses it mangles all of the symbols individually by configuring the source files, so without rewriting how kwsys is *used* in all of its downstream projects (cmake, VTK, ITK, and likely others), kwsys would likely have to be shipped as source anyways. > https://fedorahosted.org/fpc/ticket/555 I commented here that castxml is more than a "random xml app" but will be needed for an updated ITK (at least; other projects might migrate to it from gccxml as time goes on). --Ben -- 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] Making kwsys a proper library
On 08/13/2015 10:36 PM, Orion Poplawski wrote: > There is concern in Fedora that the kwsys code has become too large to > be an acceptable copylib. However, as cmake is constructed at the > moment it would be a huge undertaking for the Fedora packagers (mostly > me) to remove it downstream. So I'm asking if there is any support > upstream for making kwsys a proper library? KWSys is a copylib by design. Each project using it configures the library with a different namespace/prefix, can enable different subsets of the library, and can choose some behavior toggles. Some projects maintain local patches to their copy of KWSys that are good enough for themselves but not for upstream. KWSys cannot be shared by multiple such clients as a single library and should *never be distributed as a packaged binary*. If each of Kitware's projects using KWSys maintained the code separately under different hard-coded names (cmsys, vtksys, itksys, etc.) then no one would be expecting it to be a separate library. The shared KWSys source helps share maintenance among these projects while still each getting a custom library that never conflicts with the others. -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] Add option "--no-return-code"
On 08/13/2015 04:09 PM, A. Klitzing wrote: > We use ctest on Jenkins in a shell build step. Jenkins will FAIL > the build if the last command (ctest) will return a non-zero > return code even the configured UNSTABLE/FAIL threshold is not > reached. > > This won't be necessary if ctest could ignore the return codes. If something goes wrong with the administration of running the dashboard client, like "git fetch" fails, then CTest should report failure via a non-zero return code. Some cleanup of this was done recently to tolerate failed tests and such without making the process exit code non-zero. If you've found remaining cases where normal testing failures produce a non-zero exit from ctest then we should fix those first. Can you explain your case in more detail, please? 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] Support for Boost 1.59
On 08/13/2015 06:37 PM, Roger Leigh wrote: > The attached patch adds Boost 1.59.0/1.59 to the list of supported > versions in the FindBoost module. Applied, thanks: FindBoost: Add support for Boost 1.59 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ff5bb2ef -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] Support debug libraries for TIFF and Xerces-C libraries
On 08/13/2015 11:48 AM, rle...@codelibre.net wrote: > Done. Thanks. Patches applied: FindTIFF: Find debug and release libraries separately http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=724fa682 FindXercesC: Find debug and release libraries separately http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=021bf871 FindXercesC: Add support for 3D_1 variant of the library http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=db292564 -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] Imported OpenSSL
On 08/13/2015 09:43 AM, Konstantin Podsvirov wrote:
> Again OpenSSL :-)
>
> Topic branch (for reference)
> http://git.podsvirov.pro/?p=kitware/cmake.git;a=shortlog;h=refs/heads/topic-imported-openssl
Thanks. I've formatted the module documentation:
FindOpenSSL: Revise and format module documentation
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=79a36437
and then rebased/squashed your topic on it:
FindOpenSSL: Provide imported targets OpenSSL::{SSL,Crypto}
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=75e3a8e8
I updated the documentation wording/formatting accordingly
for the imported targets. I also updated some indentation.
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] Java support
On 08/07/2015 04:04 AM, CHEVRIER, Marc wrote: > New version of patch attached. Thanks. Applied with a few tweaks: UseJava: Add support for javah tool http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cae7bef9 However, it fails on some HP-UX machines because Java does not know how to load the native library we produce. Does anyone know what name HP-UX is expecting (I don't have access to it myself)? -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] [FEATURE REQUEST] ExternalProject disable all GIT_SUBMODULES
14.08.2015, 15:05, "David Cole" :> Isn't simply **not listing** GIT_SUBMODULES sufficient?>> On Friday, August 14, 2015, Konstantin Podsvirov wrote:>> In the next CMake we obtain the following useful thing: http://www.cmake.org/cmake/help/git-master/release/dev/ExternalProject_init_selected_submodules.html But how to disable the initialization and loading of git submodules? -->> Regards,>> Konstantin Podsvirov Module documentation: GIT_SUBMODULES ... Git submodules that shall be updated, all if empty In practice, loads the modules even if you do not specify this argument. --Regards,Konstantin Podsvirov -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [FEATURE REQUEST] ExternalProject disable all GIT_SUBMODULES
Isn't simply **not listing** GIT_SUBMODULES sufficient? On Friday, August 14, 2015, Konstantin Podsvirov wrote: > In the next CMake we obtain the following useful thing: > > > http://www.cmake.org/cmake/help/git-master/release/dev/ExternalProject_init_selected_submodules.html > > But how to disable the initialization and loading of git submodules? > > -- > Regards, > Konstantin Podsvirov > > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [FEATURE REQUEST] ExternalProject disable all GIT_SUBMODULES
In the next CMake we obtain the following useful thing: http://www.cmake.org/cmake/help/git-master/release/dev/ExternalProject_init_selected_submodules.html But how to disable the initialization and loading of git submodules? --Regards,Konstantin Podsvirov -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
