Re: [CMake] absolute library path, sorry for the question

[Bo Zhou]

https://cmake.org/cmake/help/v3.0/command/find_path.html

Please try to pass the NO_CMAKE_SYSTEM_PATH to find_path() and
find_library(), but use the HINT to pass the path to thirdparty paths.

Of course use the CMAKE_VERBOSE_MAKEFILE to check the log.

At the last check the CMakeCache.txt to verify everything is okay.

On Sun, Dec 24, 2017 at 3:50 AM, Alan W. Irwin 
wrote:

> On 2017-12-23 10:47+0100 Andreas Naumann wrote:
>
> your problem is hard to analyse. If you have a "minimal" example, which
>> shows this behavior, we could test it. In your last mail, you wrote about
>> building and installing libtiff using your own libjpeg. But than you write
>> about a later build. So something must happen in the "later build".
>>
>
> @Mario:
>
> I second everything said here by Andreas.  So I think, for example,
> that your next step should be to create a minimal example (e.g., a
> "hello, world" minimal test C executable that is [over-]linked to one
> of your libraries in a non-standard location).  Then compare your
> "make VERBOSE=1" results for that simple example on your multiple
> platforms to see whether the linking is done with the library in the
> correct non-standard location rather than the system library.
>
> Furthermore you stated in your original post that for some of your
> platforms CMake use the -l linking option to link, and you thought
> that was an issue.  Actually, that is fine if CMake also generates an
> -L option pointing to the correct non-standard location since linkers
> use the combination of -L and -l options to locate the library if it
> is not specified as an absolute path.
>
> So my guess from what you have said is you forgot about the -L option
> also generated by CMake, and, in fact, CMake is working correctly to
> link your code on all platforms.  Anyway, if your "make VERBOSE=1"
> results prove that is the case, then your next step should be to
> configure your build system so that an -rpath option is used by the
> linker so that the system loader for your executable can find the
> library in its non-standard location at run time.
>
> My own linking experience (currently with CMake-3.6.2 and higher) is just
> limited to my Debian platform at this time, but I do successfully
> use some libraries that are installed in non-standard system
> locations.  And my experience is a properly configured CMake-based
> build system links those libraries with the appropriate -rpath option
> with good results (using the library version in the non-standard
> location) both at link time and run time.
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __
>
> --
>
> 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] absolute library path, sorry for the question

[Alan W. Irwin]

On 2017-12-23 10:47+0100 Andreas Naumann wrote:

your problem is hard to analyse. If you have a "minimal" example, which shows 
this behavior, we could test it. In your last mail, you wrote about building 
and installing libtiff using your own libjpeg. But than you write about a 
later build. So something must happen in the "later build".


@Mario:

I second everything said here by Andreas.  So I think, for example,
that your next step should be to create a minimal example (e.g., a
"hello, world" minimal test C executable that is [over-]linked to one
of your libraries in a non-standard location).  Then compare your
"make VERBOSE=1" results for that simple example on your multiple
platforms to see whether the linking is done with the library in the
correct non-standard location rather than the system library.

Furthermore you stated in your original post that for some of your
platforms CMake use the -l linking option to link, and you thought
that was an issue.  Actually, that is fine if CMake also generates an
-L option pointing to the correct non-standard location since linkers
use the combination of -L and -l options to locate the library if it
is not specified as an absolute path.

So my guess from what you have said is you forgot about the -L option
also generated by CMake, and, in fact, CMake is working correctly to
link your code on all platforms.  Anyway, if your "make VERBOSE=1"
results prove that is the case, then your next step should be to
configure your build system so that an -rpath option is used by the
linker so that the system loader for your executable can find the
library in its non-standard location at run time.

My own linking experience (currently with CMake-3.6.2 and higher) is 
just limited to my Debian platform at this time, but I do successfully

use some libraries that are installed in non-standard system
locations.  And my experience is a properly configured CMake-based
build system links those libraries with the appropriate -rpath option
with good results (using the library version in the non-standard
location) both at link time and run time.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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] absolute library path, sorry for the question

[Andreas Naumann]

your problem is hard to analyse. If you have a "minimal" example, which 
shows this behavior, we could test it. In your last mail, you wrote 
about building and installing libtiff using your own libjpeg. But than 
you write about a later build. So something must happen in the "later 
build".


Interesting enough, you said, that with newer systems, you do not have 
this problem. Do these old systems use a different cmake version?


Seasons Greetings,
Andreas
Am 22.12.2017 um 17:42 schrieb Mario Emmenlauer:

Can anyone help to force cmake use absolute paths?

On 13.12.2017 11:45, Mario Emmenlauer wrote:

Thank you for your reply!! Your explanation is very helpful for writing
my own CMakeLists.txt. But in my case, I use the standard CMakeLists.txt
that comes with the libraries. For example libtiff, turbojpeg, thrift,
and many others...

As an example, I build libtiff in the following way:
 cmake ../$TIFFVERSION \
 -Wno-dev \
 -G"Unix Makefiles" \
 -DCMAKE_PREFIX_PATH="$THIRDPARTYTARGETDIR" \
 -DCMAKE_INSTALL_PREFIX="$THIRDPARTYTARGETDIR" \
 -DCMAKE_BUILD_TYPE="Release" \
 -DBUILD_SHARED_LIBS="ON" \
 -Djpeg="ON" \
 -DJPEG_INCLUDE_DIR="$THIRDPARTYTARGETDIR/include" \
 -DJPEG_LIBRARY="$THIRDPARTYTARGETDIR/lib/libjpeg.so" && \
 make VERBOSE="1" && make install

In the build log, I can see that cmake detects the jpeg library to be
'$THIRDPARTYTARGETDIR/lib/libjpeg.so'. However, in the later build, the
Makefile links with '-ljpeg' instead of '$THIRDPARTYTARGETDIR/lib/libjpeg.so'.
And this in turn will make 'ld' use '/usr/lib/x86_64-linux-gnu/libjpeg.so'
instead of my thirdparty libjpeg.

So at some point between FindJPEG.cmake and the final Makefile, cmake
changed the JPEG_LIBRARIES variable from absolute to relative. And I can
not understand why or when this happens. The documentation also does not
help me, because it explains that this should happen 'if the full path is
not know or if the full path is one of the system library dirs' (see
https://cmake.org/pipermail/cmake/2015-September/061462.html). In my case,
I override to use jpeg with a known, existing path that is not a system
library.

All the best,

Mario




On 13.12.2017 11:12, Bo Zhou wrote:

Hi

CMAKE_SKIP_RPATH usually is used for the shared module which might want to have 
the customized distributed path such as within the application. According
personal experience on POSIX systems (Linux, UNIX, OSX), always enable 
CMAKE_SKIP_RPATH for the all local shared dependencies, and to the final 
distribution,
(if needed) put shared libraries into the lib folder of distribution.

According your description, I'm not sure how did you pick up your library into 
the application from CMake, usually we have to make sure the CMake always 
chooses
the libraries from 3rd-party directory not system or another places. In our 
system, it has a variable THIRDPARTY_DIR for command FIND_PATH() to locate the
folder which contains the all built libraries, then use HINTS and NAMES in the 
command FIND_PATH() and FIND_LIBRARY() to locate the correct paths for the
pre-built libraries, so the linking should be okay.

If everything has no error, but just the application always picks up the 
system's library not the 3rd-party libraries we prepared, one solution would add
another loader script for the application, from the loader script it appends 
the local lib folder to LD_LIBRARY_PATH, then launch the actual application
executable file. A lot of commercial application on Linux solve the similar 
issue by this way.

Wish my reply is helpful.

Thank you very much.

On Wed, Dec 13, 2017 at 6:06 PM, Mario Emmenlauer > wrote:


 Dear cmake users,

 I have found good documentation on the cmake wiki about RPATH and
 its different variables, and also on the mailing lists. But somehow
 it still does not add up for me. Can you please help?

 I use cmake 3.9.5 on different platforms, CentOS 6 and Ubuntu 14.04
 amongst others. I build many standard libraries (like tiff and jpeg)
 into my own thirdparty directory, and set CMAKE_PREFIX_PATH to find
 them there. On newer Linux and Windows, cmake uses always the absolute
 path to those libraries, and everything works fine. But on older Linux
 like Ubuntu 14.04 and CentOS 6 it does not. cmake will first find the
 library in the correct absolute thirdparty directory, and I can confirm
 this by printing the 'XXX_LIBRARIES' variable in the find script. But
 later the Makefile will link with '-lxxx' instead of the full path.
 This makes 'ld' use the system library instead!

 I completely fail to understand at what point cmake changes XXX_LIBRARIES
 from an absolute path to '-lxxx', for example for libjpeg.

 I have experimented with CMAKE_SKIP_BUILD_RPATH, but it does not help.
 The only workaround I 

Re: [CMake] absolute library path, sorry for the question

[Mario Emmenlauer]

Can anyone help to force cmake use absolute paths?

On 13.12.2017 11:45, Mario Emmenlauer wrote:
> Thank you for your reply!! Your explanation is very helpful for writing
> my own CMakeLists.txt. But in my case, I use the standard CMakeLists.txt
> that comes with the libraries. For example libtiff, turbojpeg, thrift,
> and many others...
> 
> As an example, I build libtiff in the following way:
> cmake ../$TIFFVERSION \
> -Wno-dev \
> -G"Unix Makefiles" \
> -DCMAKE_PREFIX_PATH="$THIRDPARTYTARGETDIR" \
> -DCMAKE_INSTALL_PREFIX="$THIRDPARTYTARGETDIR" \
> -DCMAKE_BUILD_TYPE="Release" \
> -DBUILD_SHARED_LIBS="ON" \
> -Djpeg="ON" \
> -DJPEG_INCLUDE_DIR="$THIRDPARTYTARGETDIR/include" \
> -DJPEG_LIBRARY="$THIRDPARTYTARGETDIR/lib/libjpeg.so" && \
> make VERBOSE="1" && make install
> 
> In the build log, I can see that cmake detects the jpeg library to be
> '$THIRDPARTYTARGETDIR/lib/libjpeg.so'. However, in the later build, the
> Makefile links with '-ljpeg' instead of '$THIRDPARTYTARGETDIR/lib/libjpeg.so'.
> And this in turn will make 'ld' use '/usr/lib/x86_64-linux-gnu/libjpeg.so'
> instead of my thirdparty libjpeg.
> 
> So at some point between FindJPEG.cmake and the final Makefile, cmake
> changed the JPEG_LIBRARIES variable from absolute to relative. And I can
> not understand why or when this happens. The documentation also does not
> help me, because it explains that this should happen 'if the full path is
> not know or if the full path is one of the system library dirs' (see
> https://cmake.org/pipermail/cmake/2015-September/061462.html). In my case,
> I override to use jpeg with a known, existing path that is not a system
> library.
> 
> All the best,
> 
>Mario
> 
> 
> 
> 
> On 13.12.2017 11:12, Bo Zhou wrote:
>> Hi
>>
>> CMAKE_SKIP_RPATH usually is used for the shared module which might want to 
>> have the customized distributed path such as within the application. 
>> According
>> personal experience on POSIX systems (Linux, UNIX, OSX), always enable 
>> CMAKE_SKIP_RPATH for the all local shared dependencies, and to the final 
>> distribution,
>> (if needed) put shared libraries into the lib folder of distribution.
>>
>> According your description, I'm not sure how did you pick up your library 
>> into the application from CMake, usually we have to make sure the CMake 
>> always chooses
>> the libraries from 3rd-party directory not system or another places. In our 
>> system, it has a variable THIRDPARTY_DIR for command FIND_PATH() to locate 
>> the
>> folder which contains the all built libraries, then use HINTS and NAMES in 
>> the command FIND_PATH() and FIND_LIBRARY() to locate the correct paths for 
>> the
>> pre-built libraries, so the linking should be okay.
>>
>> If everything has no error, but just the application always picks up the 
>> system's library not the 3rd-party libraries we prepared, one solution would 
>> add
>> another loader script for the application, from the loader script it appends 
>> the local lib folder to LD_LIBRARY_PATH, then launch the actual application
>> executable file. A lot of commercial application on Linux solve the similar 
>> issue by this way.
>>
>> Wish my reply is helpful.
>>
>> Thank you very much.
>>
>> On Wed, Dec 13, 2017 at 6:06 PM, Mario Emmenlauer > > wrote:
>>
>>
>> Dear cmake users,
>>
>> I have found good documentation on the cmake wiki about RPATH and
>> its different variables, and also on the mailing lists. But somehow
>> it still does not add up for me. Can you please help?
>>
>> I use cmake 3.9.5 on different platforms, CentOS 6 and Ubuntu 14.04
>> amongst others. I build many standard libraries (like tiff and jpeg)
>> into my own thirdparty directory, and set CMAKE_PREFIX_PATH to find
>> them there. On newer Linux and Windows, cmake uses always the absolute
>> path to those libraries, and everything works fine. But on older Linux
>> like Ubuntu 14.04 and CentOS 6 it does not. cmake will first find the
>> library in the correct absolute thirdparty directory, and I can confirm
>> this by printing the 'XXX_LIBRARIES' variable in the find script. But
>> later the Makefile will link with '-lxxx' instead of the full path.
>> This makes 'ld' use the system library instead!
>>
>> I completely fail to understand at what point cmake changes XXX_LIBRARIES
>> from an absolute path to '-lxxx', for example for libjpeg.
>>
>> I have experimented with CMAKE_SKIP_BUILD_RPATH, but it does not help.
>> The only workaround I could find is to add the thirdparty directory to
>> LDFLAGS. Then 'ld' will also find the correct library.
>>
>>
>> Is this a bug, or an expected behavior? What parameters should I add
>> when I invoke cmake so that it will always use libraries with their
>> full path?
>>
>>
>> 

Re: [CMake] absolute library path, sorry for the question

[Mario Emmenlauer]

Dear Bo Zhou,

Thank you for your reply!! Your explanation is very helpful for writing
my own CMakeLists.txt. But in my case, I use the standard CMakeLists.txt
that comes with the libraries. For example libtiff, turbojpeg, thrift,
and many others...

As an example, I build libtiff in the following way:
cmake ../$TIFFVERSION \
-Wno-dev \
-G"Unix Makefiles" \
-DCMAKE_PREFIX_PATH="$THIRDPARTYTARGETDIR" \
-DCMAKE_INSTALL_PREFIX="$THIRDPARTYTARGETDIR" \
-DCMAKE_BUILD_TYPE="Release" \
-DBUILD_SHARED_LIBS="ON" \
-Djpeg="ON" \
-DJPEG_INCLUDE_DIR="$THIRDPARTYTARGETDIR/include" \
-DJPEG_LIBRARY="$THIRDPARTYTARGETDIR/lib/libjpeg.so" && \
make VERBOSE="1" && make install

In the build log, I can see that cmake detects the jpeg library to be
'$THIRDPARTYTARGETDIR/lib/libjpeg.so'. However, in the later build, the
Makefile links with '-ljpeg' instead of '$THIRDPARTYTARGETDIR/lib/libjpeg.so'.
And this in turn will make 'ld' use '/usr/lib/x86_64-linux-gnu/libjpeg.so'
instead of my thirdparty libjpeg.

So at some point between FindJPEG.cmake and the final Makefile, cmake
changed the JPEG_LIBRARIES variable from absolute to relative. And I can
not understand why or when this happens. The documentation also does not
help me, because it explains that this should happen 'if the full path is
not know or if the full path is one of the system library dirs' (see
https://cmake.org/pipermail/cmake/2015-September/061462.html). In my case,
I override to use jpeg with a known, existing path that is not a system
library.

All the best,

   Mario




On 13.12.2017 11:12, Bo Zhou wrote:
> Hi
> 
> CMAKE_SKIP_RPATH usually is used for the shared module which might want to 
> have the customized distributed path such as within the application. According
> personal experience on POSIX systems (Linux, UNIX, OSX), always enable 
> CMAKE_SKIP_RPATH for the all local shared dependencies, and to the final 
> distribution,
> (if needed) put shared libraries into the lib folder of distribution.
> 
> According your description, I'm not sure how did you pick up your library 
> into the application from CMake, usually we have to make sure the CMake 
> always chooses
> the libraries from 3rd-party directory not system or another places. In our 
> system, it has a variable THIRDPARTY_DIR for command FIND_PATH() to locate the
> folder which contains the all built libraries, then use HINTS and NAMES in 
> the command FIND_PATH() and FIND_LIBRARY() to locate the correct paths for the
> pre-built libraries, so the linking should be okay.
> 
> If everything has no error, but just the application always picks up the 
> system's library not the 3rd-party libraries we prepared, one solution would 
> add
> another loader script for the application, from the loader script it appends 
> the local lib folder to LD_LIBRARY_PATH, then launch the actual application
> executable file. A lot of commercial application on Linux solve the similar 
> issue by this way.
> 
> Wish my reply is helpful.
> 
> Thank you very much.
> 
> On Wed, Dec 13, 2017 at 6:06 PM, Mario Emmenlauer  > wrote:
> 
> 
> Dear cmake users,
> 
> I have found good documentation on the cmake wiki about RPATH and
> its different variables, and also on the mailing lists. But somehow
> it still does not add up for me. Can you please help?
> 
> I use cmake 3.9.5 on different platforms, CentOS 6 and Ubuntu 14.04
> amongst others. I build many standard libraries (like tiff and jpeg)
> into my own thirdparty directory, and set CMAKE_PREFIX_PATH to find
> them there. On newer Linux and Windows, cmake uses always the absolute
> path to those libraries, and everything works fine. But on older Linux
> like Ubuntu 14.04 and CentOS 6 it does not. cmake will first find the
> library in the correct absolute thirdparty directory, and I can confirm
> this by printing the 'XXX_LIBRARIES' variable in the find script. But
> later the Makefile will link with '-lxxx' instead of the full path.
> This makes 'ld' use the system library instead!
> 
> I completely fail to understand at what point cmake changes XXX_LIBRARIES
> from an absolute path to '-lxxx', for example for libjpeg.
> 
> I have experimented with CMAKE_SKIP_BUILD_RPATH, but it does not help.
> The only workaround I could find is to add the thirdparty directory to
> LDFLAGS. Then 'ld' will also find the correct library.
> 
> 
> Is this a bug, or an expected behavior? What parameters should I add
> when I invoke cmake so that it will always use libraries with their
> full path?
> 
> 
> Cheers,
> 
>     Mario Emmenlauer
> 
> 
> 
> PS: since I build thirdparty libraries, I prefer not to change their
> CMakeLists.txt but would rather prefer to set better cmake command line
> parameters.
> 

Re: [CMake] absolute library path, sorry for the question

[Bo Zhou]

Hi

CMAKE_SKIP_RPATH usually is used for the shared module which might want to
have the customized distributed path such as within the application.
According personal experience on POSIX systems (Linux, UNIX, OSX), always
enable CMAKE_SKIP_RPATH for the all local shared dependencies, and to the
final distribution, (if needed) put shared libraries into the lib folder of
distribution.

According your description, I'm not sure how did you pick up your library
into the application from CMake, usually we have to make sure the CMake
always chooses the libraries from 3rd-party directory not system or another
places. In our system, it has a variable THIRDPARTY_DIR for command
FIND_PATH() to locate the folder which contains the all built libraries,
then use HINTS and NAMES in the command FIND_PATH() and FIND_LIBRARY() to
locate the correct paths for the pre-built libraries, so the linking should
be okay.

If everything has no error, but just the application always picks up the
system's library not the 3rd-party libraries we prepared, one solution
would add another loader script for the application, from the loader script
it appends the local lib folder to LD_LIBRARY_PATH, then launch the actual
application executable file. A lot of commercial application on Linux solve
the similar issue by this way.

Wish my reply is helpful.

Thank you very much.

On Wed, Dec 13, 2017 at 6:06 PM, Mario Emmenlauer 
wrote:

>
> Dear cmake users,
>
> I have found good documentation on the cmake wiki about RPATH and
> its different variables, and also on the mailing lists. But somehow
> it still does not add up for me. Can you please help?
>
> I use cmake 3.9.5 on different platforms, CentOS 6 and Ubuntu 14.04
> amongst others. I build many standard libraries (like tiff and jpeg)
> into my own thirdparty directory, and set CMAKE_PREFIX_PATH to find
> them there. On newer Linux and Windows, cmake uses always the absolute
> path to those libraries, and everything works fine. But on older Linux
> like Ubuntu 14.04 and CentOS 6 it does not. cmake will first find the
> library in the correct absolute thirdparty directory, and I can confirm
> this by printing the 'XXX_LIBRARIES' variable in the find script. But
> later the Makefile will link with '-lxxx' instead of the full path.
> This makes 'ld' use the system library instead!
>
> I completely fail to understand at what point cmake changes XXX_LIBRARIES
> from an absolute path to '-lxxx', for example for libjpeg.
>
> I have experimented with CMAKE_SKIP_BUILD_RPATH, but it does not help.
> The only workaround I could find is to add the thirdparty directory to
> LDFLAGS. Then 'ld' will also find the correct library.
>
>
> Is this a bug, or an expected behavior? What parameters should I add
> when I invoke cmake so that it will always use libraries with their
> full path?
>
>
> Cheers,
>
> Mario Emmenlauer
>
>
>
> PS: since I build thirdparty libraries, I prefer not to change their
> CMakeLists.txt but would rather prefer to set better cmake command line
> parameters.
>
>
> References:
> https://cmake.org/Wiki/CMake_RPATH_handling
> https://cmake.org/pipermail/cmake/2015-September/061462.html
>
>
>
> --
> BioDataAnalysis GmbH, Mario Emmenlauer  Tel. Buero: +49-89-74677203
> Balanstr. 43   mailto: memmenlauer * biodataanalysis.de
> D-81669 München  http://www.biodataanalysis.de/
> --
>
> 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