Re: [cmake-developers] [Patch 5/5] Improved WIX support
On 09/09/2016 10:54 AM, Stuermer, Michael SP/HZA-ZSEP wrote: The details you miss if you are not using the features ... thanks for the hint, here is corrected patch. Michael Thanks. I merged to "next" with small changes. 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] [Patch 5/5] Improved WIX support
> -Original Message- > From: Nils Gladitz [mailto:nilsglad...@gmail.com] > Sent: Friday, September 09, 2016 8:33 AM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] [Patch 5/5] Improved WIX support > > On 09/06/2016 01:26 PM, Stuermer, Michael SP/HZA-ZSEP wrote: > > Here it is. > > > > The patch only seems to allow patching Features generated for components > but not Features generated for component groups. > Is that intentional or an oversight? > > I think we should allow patching for both. > > Nils > The details you miss if you are not using the features ... thanks for the hint, here is corrected patch. Michael 0001-enabled-patching-of-WIX-Feature-tags.patch Description: 0001-enabled-patching-of-WIX-Feature-tags.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] [Patch 5/5] Improved WIX support
On 09/06/2016 01:26 PM, Stuermer, Michael SP/HZA-ZSEP wrote: Here it is. The patch only seems to allow patching Features generated for components but not Features generated for component groups. Is that intentional or an oversight? I think we should allow patching for both. 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] [Patch 5/5] Improved WIX support
On 09/06/2016 01:26 PM, Stuermer, Michael SP/HZA-ZSEP wrote: Yes I tried, didn't work somehow. Never mind, the current approach works. It should have worked. I've added a new working test case to my suite: https://github.com/ngladitz/cmake-wix-testsuite/tree/master/feature_ref_in_product I'll look into integrating your patch for consistency nonetheless but it should not really have been required for your use case. 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] [Patch 5/5] Improved WIX support
> -Original Message-
> From: Nils Gladitz [mailto:nilsglad...@gmail.com]
> Sent: Tuesday, August 16, 2016 12:52 PM
> To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers
> Subject: Re: [cmake-developers] [Patch 5/5] Improved WIX support
>
> On 08/16/2016 11:15 AM, Stuermer, Michael SP/HZA-ZSEP wrote:
>
> >> There is precedence in cmWIXFilesSourceWriter::EmitComponentFile() so
> >> I think such an interface change would be fine.
> >>
> > Ok I'll do this. Should solve all issues and doubts hopefully.
>
> Great. Thanks.
>
Here it is.
> >
> > Adding FeatureRef to #PRODUCT does not work. I get the following
> message:
> >
> > features.wixobj : error LGHT0095 : Multiple primary references were found
> for Feature '@feature@' in Feature 'ProductFeature' and Product '{@guid@}'
>
> Did you try with IgnoreParent="yes" on your FeatureRef element?
> It makes sense that there can only be one root-Feature.
>
Yes I tried, didn't work somehow. Never mind, the current approach works.
> Nils
0003-enabled-patching-of-WIX-Feature-tags.patch
Description: 0003-enabled-patching-of-WIX-Feature-tags.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] [Patch 5/5] Improved WIX support
On 08/16/2016 11:15 AM, Stuermer, Michael SP/HZA-ZSEP wrote:
There is precedence in cmWIXFilesSourceWriter::EmitComponentFile() so I
think such an interface change would be fine.
Ok I'll do this. Should solve all issues and doubts hopefully.
Great. Thanks.
Adding FeatureRef to #PRODUCT does not work. I get the following message:
features.wixobj : error LGHT0095 : Multiple primary references were found for
Feature '@feature@' in Feature 'ProductFeature' and Product '{@guid@}'
Did you try with IgnoreParent="yes" on your FeatureRef element?
It makes sense that there can only be one root-Feature.
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] [Patch 5/5] Improved WIX support
> -Original Message-
> From: Nils Gladitz [mailto:nilsglad...@gmail.com]
> Sent: Tuesday, August 16, 2016 10:54 AM
> To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers
> Subject: Re: [cmake-developers] [Patch 5/5] Improved WIX support
>
> On 08/16/2016 10:15 AM, Stuermer, Michael SP/HZA-ZSEP wrote:
>
> >
> > After having look at the code for some minutes I remember why patching
> the ref instead oft he feature was my way to go:
> >
> > The feature is written to file in
> cmWIXFeaturesSourceWriter::EmitFeatureForComponent(), where I do not
> have any patch information available. This means I'd have to change the
> signature of both EmitFeatureForComponent and
> EmitFeatureForComponentGroup and pass a reference to the patch instance
> along. Multiple occurrence of IDs can happen, but the patch will only be
> applied once because applied fragments are erased immediately after
> writing them to the stream.
> >
> > So after all for me this was a consideration of a 1-line change vs. changing
> class interfaces an passing object instances to where it might not be
> desirable.
>
> There is precedence in cmWIXFilesSourceWriter::EmitComponentFile() so I
> think such an interface change would be fine.
>
Ok I'll do this. Should solve all issues and doubts hopefully.
> >
> > I agree the commit message of the patch is not accurate enough and if
> there is way to add custom WIX-components to features without changing
> the cpack source I'd be happy to do so. But so far I tried several approaches
> and neither worked (see below).
> >
> >> This would not be any more convenient but would certainly match
> >> expectations and be less ill defined.
> >> e.g. when I specify a patch for a Feature I expect that the Feature
> >> with the given ID gets patched.
> >>
> >> Arguments against patching a FeatureRef instead are:
> >> - There can be n FeatureRef elements for any Feature element in which
> >> case it would not be obvious if the patch should be applied to one
> >> (which?) or all of these
> > The way the patch was implemented only the featurerefs in the generated
> features.wxs file would be patched and there should not be any double
> occurences of a feature ref.
> >
> >> - While similar FeatureRef and Feature don't take the same Child
> >> elements
> > Right, and if both Feature and FeatureRef would be patchable we would be
> in trouble. For the lazy one: this is not the case at the moment so we would
> not need to worry about it (but it's very nice). For the correct one: We could
... meant NOT very nice, of course ...
> introduce another attribute to CPackWixFragment called "Type" where type
> of the XML node to be patched could be stored. But this would introduce
> additional complexity to the cmWIXPatch class...
>
> There is no use case to be able to patch both FeatureRef and Feature
> elements when Feature elements can be patched directly.
>
Right.
> >
> >> - You can already define your own FeatureRef elements (referencing
> >> any of the pre-existing Feature elements if wanted) without having to
> >> use the patch mechanism
> >>
> > I tried this like this (in a separate additional .wxs source file added with
> CPACK_WIX_EXTRA_SOURCES):
> >
> > http://schemas.microsoft.com/wix/2006/wi";>
> >
> > Directory="INSTALL_ROOT">
> >
> >
> >
> >
> > IgnoreParent="yes">
> >
> >
> >
> >
> >
> > Did not work, the registry value was not set. Using the proposed approach
> it worked. Do I have to reference it somehow different?
>
> The linker only includes object files which provide a symbol that is required
> by an object already included.
> Your source file has a single symbol for the Component "SetRegistryValues"
> but that symbol (I assume) is not required by any of the other objects which
> the linker includes.
>
> You could e.g. add the FeatureRef to a custom WIX.template.in (which has
> the main entry point and is therefor always included), or supply a patch for
> the Product element (#PRODUCT), or create any kind of valid reference to
> your custom source file (if any reference is resolved through your custom
> source the entire object gets included).
>
Adding FeatureRef to #PRODUCT does not work. I get the following message:
features.wixobj : error LGHT0095 : Multiple primary references were found for
Feature '@feature@' in Feature 'ProductFeature' and Product '{@guid@}'
Re: [cmake-developers] [Patch 5/5] Improved WIX support
On 08/16/2016 10:15 AM, Stuermer, Michael SP/HZA-ZSEP wrote: After having look at the code for some minutes I remember why patching the ref instead oft he feature was my way to go: The feature is written to file in cmWIXFeaturesSourceWriter::EmitFeatureForComponent(), where I do not have any patch information available. This means I'd have to change the signature of both EmitFeatureForComponent and EmitFeatureForComponentGroup and pass a reference to the patch instance along. Multiple occurrence of IDs can happen, but the patch will only be applied once because applied fragments are erased immediately after writing them to the stream. So after all for me this was a consideration of a 1-line change vs. changing class interfaces an passing object instances to where it might not be desirable. There is precedence in cmWIXFilesSourceWriter::EmitComponentFile() so I think such an interface change would be fine. I agree the commit message of the patch is not accurate enough and if there is way to add custom WIX-components to features without changing the cpack source I'd be happy to do so. But so far I tried several approaches and neither worked (see below). This would not be any more convenient but would certainly match expectations and be less ill defined. e.g. when I specify a patch for a Feature I expect that the Feature with the given ID gets patched. Arguments against patching a FeatureRef instead are: - There can be n FeatureRef elements for any Feature element in which case it would not be obvious if the patch should be applied to one (which?) or all of these The way the patch was implemented only the featurerefs in the generated features.wxs file would be patched and there should not be any double occurences of a feature ref. - While similar FeatureRef and Feature don't take the same Child elements Right, and if both Feature and FeatureRef would be patchable we would be in trouble. For the lazy one: this is not the case at the moment so we would not need to worry about it (but it's very nice). For the correct one: We could introduce another attribute to CPackWixFragment called "Type" where type of the XML node to be patched could be stored. But this would introduce additional complexity to the cmWIXPatch class... There is no use case to be able to patch both FeatureRef and Feature elements when Feature elements can be patched directly. - You can already define your own FeatureRef elements (referencing any of the pre-existing Feature elements if wanted) without having to use the patch mechanism I tried this like this (in a separate additional .wxs source file added with CPACK_WIX_EXTRA_SOURCES): http://schemas.microsoft.com/wix/2006/wi";> Did not work, the registry value was not set. Using the proposed approach it worked. Do I have to reference it somehow different? The linker only includes object files which provide a symbol that is required by an object already included. Your source file has a single symbol for the Component "SetRegistryValues" but that symbol (I assume) is not required by any of the other objects which the linker includes. You could e.g. add the FeatureRef to a custom WIX.template.in (which has the main entry point and is therefor always included), or supply a patch for the Product element (#PRODUCT), or create any kind of valid reference to your custom source file (if any reference is resolved through your custom source the entire object gets included). 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] [Patch 5/5] Improved WIX support
> -Original Message- > From: Nils Gladitz [mailto:nilsglad...@gmail.com] > Sent: Friday, August 12, 2016 1:50 PM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] [Patch 5/5] Improved WIX support > > On 08/12/2016 11:50 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > > > > >> Patch 5 seems to implement patching of FeatureRef rather than the > >> original Feature elements. > >> I am not sure if this is what you intended but this could be error > >> prone given that there could in theory be any number (0-n) FeatureRef > >> elements for any corresponding Feature element. > >> > >> Nils > > The intention was to be able to add custom components that are added as > extra .wxs source files to certain features. If there are more convenient ways > to do this I will be happy to change the implementation or adapt my WIX > project. But so far this seemed to be a very easy and intuitive solution: the > additional component references are added in the same place where all > other component references are added as well. > > I understand the general intention but not why you elected to patch > FeatureRef elements instead of the Feature elements themselves. > After having look at the code for some minutes I remember why patching the ref instead oft he feature was my way to go: The feature is written to file in cmWIXFeaturesSourceWriter::EmitFeatureForComponent(), where I do not have any patch information available. This means I'd have to change the signature of both EmitFeatureForComponent and EmitFeatureForComponentGroup and pass a reference to the patch instance along. Multiple occurrence of IDs can happen, but the patch will only be applied once because applied fragments are erased immediately after writing them to the stream. So after all for me this was a consideration of a 1-line change vs. changing class interfaces an passing object instances to where it might not be desirable. I agree the commit message of the patch is not accurate enough and if there is way to add custom WIX-components to features without changing the cpack source I'd be happy to do so. But so far I tried several approaches and neither worked (see below). > This would not be any more convenient but would certainly match > expectations and be less ill defined. > e.g. when I specify a patch for a Feature I expect that the Feature with the > given ID gets patched. > > Arguments against patching a FeatureRef instead are: > - There can be n FeatureRef elements for any Feature element in which case > it would not be obvious if the patch should be applied to one > (which?) or all of these The way the patch was implemented only the featurerefs in the generated features.wxs file would be patched and there should not be any double occurences of a feature ref. > - While similar FeatureRef and Feature don't take the same Child elements Right, and if both Feature and FeatureRef would be patchable we would be in trouble. For the lazy one: this is not the case at the moment so we would not need to worry about it (but it's very nice). For the correct one: We could introduce another attribute to CPackWixFragment called "Type" where type of the XML node to be patched could be stored. But this would introduce additional complexity to the cmWIXPatch class... > - You can already define your own FeatureRef elements (referencing any of > the pre-existing Feature elements if wanted) without having to use the > patch mechanism > I tried this like this (in a separate additional .wxs source file added with CPACK_WIX_EXTRA_SOURCES): http://schemas.microsoft.com/wix/2006/wi";> Did not work, the registry value was not set. Using the proposed approach it worked. Do I have to reference it somehow different? > Nils > . Michael -- 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 5/5] Improved WIX support
I'll provide a patch where I change it to patching the actual feature XML tags. Michael > -Original Message- > From: Nils Gladitz [mailto:nilsglad...@gmail.com] > Sent: Friday, August 12, 2016 1:50 PM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] [Patch 5/5] Improved WIX support > > On 08/12/2016 11:50 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > > > > >> Patch 5 seems to implement patching of FeatureRef rather than the > >> original Feature elements. > >> I am not sure if this is what you intended but this could be error > >> prone given that there could in theory be any number (0-n) FeatureRef > >> elements for any corresponding Feature element. > >> > >> Nils > > The intention was to be able to add custom components that are added as > extra .wxs source files to certain features. If there are more convenient ways > to do this I will be happy to change the implementation or adapt my WIX > project. But so far this seemed to be a very easy and intuitive solution: the > additional component references are added in the same place where all > other component references are added as well. > > I understand the general intention but not why you elected to patch > FeatureRef elements instead of the Feature elements themselves. > > This would not be any more convenient but would certainly match > expectations and be less ill defined. > e.g. when I specify a patch for a Feature I expect that the Feature with the > given ID gets patched. > > Arguments against patching a FeatureRef instead are: > - There can be n FeatureRef elements for any Feature element in which case > it would not be obvious if the patch should be applied to one > (which?) or all of these > - While similar FeatureRef and Feature don't take the same Child elements > - You can already define your own FeatureRef elements (referencing any of > the pre-existing Feature elements if wanted) without having to use the > patch mechanism > > 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] [Patch 5/5] Improved WIX support
On 08/12/2016 11:50 AM, Stuermer, Michael SP/HZA-ZSEP wrote: Patch 5 seems to implement patching of FeatureRef rather than the original Feature elements. I am not sure if this is what you intended but this could be error prone given that there could in theory be any number (0-n) FeatureRef elements for any corresponding Feature element. Nils The intention was to be able to add custom components that are added as extra .wxs source files to certain features. If there are more convenient ways to do this I will be happy to change the implementation or adapt my WIX project. But so far this seemed to be a very easy and intuitive solution: the additional component references are added in the same place where all other component references are added as well. I understand the general intention but not why you elected to patch FeatureRef elements instead of the Feature elements themselves. This would not be any more convenient but would certainly match expectations and be less ill defined. e.g. when I specify a patch for a Feature I expect that the Feature with the given ID gets patched. Arguments against patching a FeatureRef instead are: - There can be n FeatureRef elements for any Feature element in which case it would not be obvious if the patch should be applied to one (which?) or all of these - While similar FeatureRef and Feature don't take the same Child elements - You can already define your own FeatureRef elements (referencing any of the pre-existing Feature elements if wanted) without having to use the patch mechanism 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] [Patch 5/5] Improved WIX support
> -Original Message- > From: Nils Gladitz [mailto:nilsglad...@gmail.com] > Sent: Friday, August 12, 2016 9:42 AM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] [Patch 5/5] Improved WIX support > > On 07/20/2016 03:58 PM, Stuermer, Michael SP/HZA-ZSEP wrote: > > > Using the patchfile support I managed to implement the service installation > issue I had, so the unnecessary features from the last patch are removed > now. > > > > I tested all patches separately and hope they work now. > > > > looking forward for feedback, > > > > best regrads, > > Michael > > > > Patch 5 seems to implement patching of FeatureRef rather than the original > Feature elements. > I am not sure if this is what you intended but this could be error prone given > that there could in theory be any number (0-n) FeatureRef elements for any > corresponding Feature element. > > Nils The intention was to be able to add custom components that are added as extra .wxs source files to certain features. If there are more convenient ways to do this I will be happy to change the implementation or adapt my WIX project. But so far this seemed to be a very easy and intuitive solution: the additional component references are added in the same place where all other component references are added as well. Michael -- 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 5/5] Improved WIX support
On 07/20/2016 03:58 PM, Stuermer, Michael SP/HZA-ZSEP wrote: Using the patchfile support I managed to implement the service installation issue I had, so the unnecessary features from the last patch are removed now. I tested all patches separately and hope they work now. looking forward for feedback, best regrads, Michael Patch 5 seems to implement patching of FeatureRef rather than the original Feature elements. I am not sure if this is what you intended but this could be error prone given that there could in theory be any number (0-n) FeatureRef elements for any corresponding Feature element. 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
