Re: [CMake] cmake end user vs. developer rpath handling

[Zakrzewski, Jakub]

From: CMake  on behalf of DIXON, MARK C. 

Sent: 08 October 2019 17:25
To: cmake@cmake.org
Subject: [CMake] cmake end user vs. developer rpath handling

>Sometimes, this does the trick. When it does, I'm very happy:
>
>   cmake -D CMAKE_INSTALL_RPATH="/my/rpath" source_dir
>
>I'm currently looking at a package
>(https://github.com/PointCloudLibrary/pcl) where this has no bearing on
>the rpath of the installed software - I seem to get something set by the
>developer.

That "something" seems to be line 257:
set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/${LIB_INSTALL_DIR}")

>Is there a way to reliably add to, or at least override, the developer's
>rpath in any cmake-built software?


Short of editing the build system scripts? I doubt...
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] CMake and Ninja, RERUN_CMAKE useless?

[Nagurne, James via CMake]

Hi all,

My question comes from a Ninja generator build system, and is specifically 
about an internal rule generated by cmake.
What is the purpose of the RERUN_CMAKE rule generated by CMake with a Ninja 
generator?

In the current repo, the only reference to this rule is in 
WriteTargetRebuildManifest 
here
At line 1285, the rule is written out, seemingly as-is.

According to lines 1274 to 1284, the only actual behavior of this command, 
which is executed whenever the source CMakeLists.txt file, files included from 
the CMakeLists, and some other CMake installation files change, is:
cmake -S  -B 

This seems completely insufficient for "re-running" cmake. The most obvious 
flaw is the absence of the generator. When I've seen this rule fire, my Ninja 
build system adds a useless Makefile to the build system, and then (hopefully) 
continues building as if nothing had been done at all, without so much as 
inspecting that Makefile.

What about command-line arguments like -D?

Am I missing the purpose of this rule or potentially doing something 
non-standard? The reason I send an email is because this behavior is sending my 
project into a cmake loop where it detects build.ninja is out of date, re-runs 
cmake to generate a Makefile instead of a ninja build system, and then 
infinitely repeats because it never actually re-ran anything.

Thanks,
JB
Code Generation
Texas Instruments
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] ?==?utf-8?q? ?==?utf-8?q? ?= Looking for an explanation: What exactly means "install" in cmake language

[Cornelis Bockemühl]

After stripping down the question to "can I install an imported target"? - with 
the purpose to copy the shared libraries also into the lib directory of the 
importing project - I could actually also use Google and look for an answer 
that somebody else might have been asked.

And indeed: this seems to be a rather common question!

And the "official answer" seems to be something like "this bug is a feature". 
It must have been a change request already years ago, and it was refused with 
different arguments, like:

1) proper RPATH handling is not possible in this case, because CMake cannot 
know the way how the shared library was built initially, so it is not able to 
manipulate it.

At first this looks plausible, but then I was thinking that in Linux you always 
deal with ELF binaries, and there you have tools to manipulate RPATH/RUNPATH 
easily, and in Windows there is nothing similar - and others I don't know...

2) the target is already installed, so it makes no sense to install it again; 
it would only be a waste of disk space.

Well, in my case it would make a lot of sense, and also for any kind of 
packager that might use the install directory it would be much easier if all 
the stuff is already in one location.

3...) maybe others - I did not follow further.

In any case the conclusion is: It's like it is, and all my confusion came 
basically from this strange behaviour - that "install" is not always really 
"install" (but now I know at least when and why!). And the only way around - if 
I want to avoid the configure_file solution - would be to do some proper 
install(FILES...) instead - together with a little hacking regarding what the 
right files actually are.

Best regards, Cornelis
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] cmake end user vs. developer rpath handling

[DIXON, MARK C.]

Hi,

I install lots of software packages under Linux and, increasingly, they 
use cmake instead of other methods (congratulations!)

Frustratingly for me, I seem to keep ending up in a fight with the various 
developer's cmake config files over what rpath should be set, among other 
things. Obviously, I think I know best, so would like to know how to win 
please :)

Sometimes, this does the trick. When it does, I'm very happy:

   cmake -D CMAKE_INSTALL_RPATH="/my/rpath" source_dir

I'm currently looking at a package 
(https://github.com/PointCloudLibrary/pcl) where this has no bearing on 
the rpath of the installed software - I seem to get something set by the 
developer.

Is there a way to reliably add to, or at least override, the developer's 
rpath in any cmake-built software?

Thanks,

Mark
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] extending CMAKE__LINK_EXECUTABLE

[Fred Baksik]

On Tue, Oct 8, 2019, at 9:08 AM, Setzer Sebastian (CM-CI2/ECS2) via CMake wrote:
> Dear list,

> I need to run a tool after building an executable, which will modify the 
> executable itself.

> I intend to extend the toolchain for this, because it shall be done for every 
> executable on this particular operating system.

> 

> I think for this purpose, I need to change the rule 
> CMAKE__LINK_EXECUTABLE.

> And I think I can’t put multiple commands into that rule, so I need to write 
> a wrapper which will be called instead of the normal linker, and the calls 
> the normal linker and then that special tool.

> 

> Right, so far?

> 

> Now I’d like to pass a few additional parameters to this tool, which I’d like 
> to get from a special target property.

> 

> The rule currently looks like this:

> set(CMAKE_C_LINK_EXECUTABLE "   
>   -o  ")

> 

> And I wonder what these placeholders in angle brackets mean, and if there are 
> more placeholders available. The manual doesn’t say anything about this, 
> unfortunately:

> https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_LINK_EXECUTABLE.html

> 

> Is there, for example, a way to access arbitrary target properties?

> Or do I need to hide my special parameters somewhere in the LINK_OPTIONS 
> property?

> 

> Regards,

> Sebastian

> -- 
> 

I don't see how running arbitrary commands is possible in this way.

If you want to avoid the boilerplate of adding a post-build custom command use 
a macro that performs the add_executable() and add_custom_command(). Then use 
the macro for each of the executable.

Those markers aren't specified because it is part of implementation details of 
the Makefile (and Ninja?) generator and these items tend not to be documented 
for that reason (at least that is what I have come to understand from comments 
made on gitlab and developers mailing list).

--
Fred-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] ?==?utf-8?q? ?==?utf-8?q? ?= Looking for an explanation: What exactly means "install" in cmake language

[Cornelis Bockemühl]

Actually I implemented yesterday a way how to copy the shared libs - with 
configure_file() and a lot of frickling around with the lib names myself, like 
finding out the extension on Linux and Windows, etc.

Now I tried to include the following command in the "shlibbiConfig.cmake.in" 
file:

install(TARGETS shlibbi::SHLIBbi
    EXPORT
    shlibbi-targets
    LIBRARY DESTINATION
    ${CMAKE_INSTALL_LIBDIR})

With this, I would expect that I am not "copying files", but "installing 
targets" - so actually a more abstract and powerful level - if it works! Since 
the generated shlibbiConfig.cmake would finally run in the context of the 
importing project, i.e. during a find_package() call, it should actually 
transfer the lib files from that imported target into the CMAKE_INSTALL_LIBDIR 
of the calling project - so exactly what I need.

However, the result is an error message:
 
install TARGETS given target "shlibbi::SHLIBbi" which does not exist.
Well, it exists, because it is generated in the auto-generated 
shlibbiTargets.cmake file like this:

add_library(shlibbi::SHLIBbi SHARED IMPORTED)

and that shlibbiTargets.cmake was called inside shlibbiConfig.cmake BEFORE the 
above install(TARGETS...) call.

Conclusion: "imported targets" are not "fully valid targets", because while I 
can now refer to that imported target, like with an #include ... in my source 
code, or with a successful link to the library, but obviously I cannot 
"install" that target.

So my question can be even more specified now: Is there a way around this 
"install blockage" that would allow me to do the required transfer of the 
shared library into the lib folder of the calling project - and then even 
further also to the caller's calling project? I mean: with the effect of first 
moving libshlibbi.so to the lib directory of the shlibbu project, and then both 
the libshlibbi.so and the libshlibbu.so to the example project - of course 
including the required adaptation of the RPATH

Because that is what I learned: doing the transfer with install() instead of a 
file copy through configure_file gives me not only the more abstract level of 
project organization, but also takes care of the RPATH...

Best regards,
Cornelis

Am Dienstag, Oktober 08, 2019 14:07 CEST, cornelis  
schrieb:
 Thanks for that hint! But for me the RPATH stuff is only a supplement, because 
in the context of a Paraview based project, most of my shared libs are plugins, 
and for these PV comes with its own mechanism to find them. But then all the 
more important is the question about actually copying the libs - to a specific 
location where the plugin finding procedure finds them! Regards, Cornelis
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] extending CMAKE__LINK_EXECUTABLE

[Setzer Sebastian (CM-CI2/ECS2) via CMake]

Dear list,
I need to run a tool after building an executable, which will modify the 
executable itself.
I intend to extend the toolchain for this, because it shall be done for every 
executable on this particular operating system.

I think for this purpose, I need to change the rule 
CMAKE__LINK_EXECUTABLE.
And I think I can't put multiple commands into that rule, so I need to write a 
wrapper which will be called instead of the normal linker, and the calls the 
normal linker and then that special tool.

Right, so far?

Now I'd like to pass a few additional parameters to this tool, which I'd like 
to get from a special target property.

The rule currently looks like this:
set(CMAKE_C_LINK_EXECUTABLE"  
   -o  ")

And I wonder what these placeholders in angle brackets mean, and if there are 
more placeholders available. The manual doesn't say anything about this, 
unfortunately:
https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_LINK_EXECUTABLE.html

Is there, for example, a way to access arbitrary target properties?
Or do I need to hide my special parameters somewhere in the LINK_OPTIONS 
property?

Regards,
Sebastian
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] ?= Looking for an explanation: What exactly means "install" in cmake language

[cornelis]

  
  
Thanks for that hint! But for me the RPATH stuff is only a supplement, because 
in   the context of a Paraview based project, most of my shared libs are 
plugins, and for these PV comes with its own mechanism to find them.
  

  
But then all the more important is the question about actually copying the libs 
- to a specific location where the plugin finding procedure finds them!
  

  
Regards, Cornelis
  

  
  

  
  
  
  
  
>   
> On 08.10.2019 at 13:10, Eric Noulardwrote:
>   
>   
>   
>
>   
>   
>   
> Le   mar. 8 oct. 2019 à   12:52, Cornelis Bockemühl   
>  a écrit   :
>   
> >  One more finding: the "magic" that QtCreator does to start example also 
> > without any additional fiddling with the RPATH: it already contains a 
> > RUNPATH, and this points to the shared library libshlibbu.so in it's build 
> > tree location, not in the installed location - and the same with 
> > libshlibbu.so.
> >   
> >  And the "install" process indeed handles the RPATH/RUNPATH: it simply 
> > removes it!
> >   
> >  Meaning: it I want to end up what I initially expected, I have to do two 
> > additional things manually (or maybe there is an automatic way??):
> >   
> >  1) copy the shared libraries to the "example" install directory tree
> >  2) add some RPATH or RUNPATH setting to all the binaries that need it
>   
>
>   
> You should read how RPATH handling is done with CMake.
>   
> see:   
> https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling
>   
>
>   
> As you already noted there is a build RPATH and an install RPATH.
>   
> The first is used when building the second replace the first after 
> installation takes place.
>   
>   
>
>  --
>   
>   
>   
>   
>   
> Eric
> 
 -- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS

[Alexander]

Hi Craig,
Thank you for this information. I never tried this way with the own
CMakeLists.txt and I should try it. I found one efficient workaround
however which is the option
-DCMAKE_CXX_STANDARD_LIBRARIES=/DEF:additionalDefFile.def. It turned that
the content of CMAKE_CXX_STANDARD_LIBRARIES is pushed to the linking
command without any preprocessing which is exactly what I wanted
(reference:
https://cmake.cmake.narkive.com/UuC3PGkF/how-to-append-arbitrary-linker-options).
What about stripping of the /DEF:option from CMAKE_SHARED_LINKER_FLAGS I
see I would better ask CMake developers (cmake-develop...@cmake.org) or
submit a bug.

--
Best Regards,
Alexander

On Sat, 5 Oct 2019 at 10:33, Craig Scott  wrote:

>
>
> On Sat, Oct 5, 2019 at 12:59 AM Alexander 
> wrote:
>
>> Dear Cristian,
>>
>> It would better for me not modifying CMakeFiles.txt, because as I wrote
>> it is 3rd party stuff (we just download it and build, but some different
>> way).
>> My concern is why the command line option -DCMAKE_SHARED_LINKER_FLAGS
>> deliberately ignores /DEF: option. It this behavior expected? What is the
>> logic behind this behavior? Why not simply allow /DEF in
>> CMAKE_SHARED_LINKER_FLAGS and not cut it?
>>
>
>
> You don't have to modify the third party CMakeLists.txt file to achieve
> what Cristian suggested. You can call target_sources() on the third party
> target from your own CMakeLists.txt file to add .def files to their
> target. You don't have to be in the same directory scope as the target to
> use target_sources() on it.
>
> I'm not familiar with why CMake is stripping out the /DEF: option in your
> case, but I suspect it would be related to the way CMake expects to add
> such options based on .def files given as sources.
>
>
>
>> On Fri, 4 Oct 2019 at 16:54, Cristian Adam 
>> wrote:
>>
>>> Hi,
>>>
>>> You should simply add the my_defs.def file as a source files to
>>> add_library/add_executable.
>>> CMake will automagically pass /DEF: to the linker with my_defs.def
>>>
>>> Cheers,
>>> Cristian.
>>>
>>> On Fri, Oct 4, 2019 at 4:45 PM Alexander 
>>> wrote:
>>>
 Hello,

 I would like to add an extra .defs file for linking of a DLL on
 Windows. I want to use the CMake command line option
 -DCMAKE_SHARED_LINKER_FLAGS="/DEF:my_defs.defs". I expect that besides the
 automatically generated
 /bin/.dir/Release/exports.def i see additionally
 /DEF:my_defs.defs in the resulting linking command, but it does not happen.

 What is especially irritating that CMake deliberately removes namely
 /DEF: from CMAKE_SHARED_LINKER_FLAGS. Any other word combinations (if I
 write  /DEF111:my_defs.def for example) are accepted and I see them the
 linking command.

 I tried to reach the same goal using a CMakeLists.txt like this:

 set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /DEF:my_defs.def")

 but it did not help - the same way CMake removes my /DEF: option.

 Could you please open a ticket to fix this behavior to not cut /DEF:
 option from CMAKE_***_LINKER_FLAGS?

 On my opinion CMake should not interpret or modify the content of
 CMAKE_SHARED_LINKER_FLAGS value, but should put it entirely as the user
 specified it. If you have another opinion, please provide any other
 possibility to pass an arbitrary arguments to the linking command "as is"
 so that they are not modified.

 Any workaround is highly appreciated (better command-line, because we
 build 3rd party software and it would not really fine to change
 CMakeLists.txt)

 --
 Best Regards,
 Alexander Samoilov
 Build & Integration Engineer
 Compart AG, 71034 Böblingen Germany

>>>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
> Get the hand-book for every CMake user: Professional CMake: A Practical
> Guide 
> Consulting services (CMake, C++, build/release processes):
> https://crascit.com/services
>
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] ?= Looking for an explanation: What exactly means "install" in cmake language

[Eric Noulard]

Le mar. 8 oct. 2019 à 12:52, Cornelis Bockemühl  a
écrit :

> One more finding: the "magic" that QtCreator does to start example also
> without any additional fiddling with the RPATH: it already contains a
> RUNPATH, and this points to the shared library libshlibbu.so in it's build
> tree location, not in the installed location - and the same with
> libshlibbu.so.
>
> And the "install" process indeed handles the RPATH/RUNPATH: it simply
> removes it!
>
> Meaning: it I want to end up what I initially expected, I have to do two
> additional things manually (or maybe there is an automatic way??):
>
> 1) copy the shared libraries to the "example" install directory tree
> 2) add some RPATH or RUNPATH setting to all the binaries that need it
>

You should read how RPATH handling is done with CMake.
see:
https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling

As you already noted there is a build RPATH and an install RPATH.
The first is used when building the second replace the first after
installation takes place.

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] ?==?utf-8?q? ?==?utf-8?q? ?= Looking for an explanation: What exactly means "install" in cmake language

[Cornelis Bockemühl]

One more finding: the "magic" that QtCreator does to start example also without 
any additional fiddling with the RPATH: it already contains a RUNPATH, and this 
points to the shared library libshlibbu.so in it's build tree location, not in 
the installed location - and the same with libshlibbu.so.

And the "install" process indeed handles the RPATH/RUNPATH: it simply removes 
it!

Meaning: it I want to end up what I initially expected, I have to do two 
additional things manually (or maybe there is an automatic way??):

1) copy the shared libraries to the "example" install directory tree
2) add some RPATH or RUNPATH setting to all the binaries that need it

Regards, Cornelis
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] ?==?utf-8?q? ?==?utf-8?q? ?= Looking for an explanation: What exactly means "install" in cmake language

[Cornelis Bockemühl]

The missing link to my "cmake teacher web page": 
https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/

Regards, Cornelis
-- 

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:
https://cmake.org/mailman/listinfo/cmake