[CMake] GNUInstallDir for CMake export files

2014-09-30 Thread Nico Schlömer
Hi all,

into which of the directories listed in [1] are the CMake export files
(*Config.cmake, *Target.cmake,...) supposed to go?

Cheers,
Nico


[1] http://www.cmake.org/cmake/help/v3.0/module/GNUInstallDirs.html
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake


Re: [CMake] [ITK-dev] find_package issues with ITK and VTK (and SlicerExecution Model)

2014-09-30 Thread Brad King
On 09/30/2014 11:13 AM, Bradley Lowekamp wrote:
> Do you have a suggestion on how to conditionally include a
> module if it's available? e.g. Use ITKDeprecated if ITK was
> configure with it?

 find_package(ITK REQUIRED)
 set(MY_ITK_COMPONENTS ...) # list required mods here
 if(";${ITK_MODULES_ENABLED};" MATCHES ";ITKDeprecated;")
   list(APPEND MY_ITK_COMPONENTS ITKDeprecated)
 endif()
 itk_module_config(ITK ${MY_ITK_COMPONENTS})

I think the if() line could also be written

 if(TARGET ITKDeprecated)

but I don't remember off the top of my head whether the
library names and module names always match exactly.

-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


Re: [CMake] [ITK-dev] find_package issues with ITK and VTK (and SlicerExecution Model)

2014-09-30 Thread Bradley Lowekamp
Brad,

Do you have a suggestion on how to conditionally include a module if it's 
available? e.g. Use ITKDeprecated if ITK was configure with it?

Thanks,
Brad

On Sep 30, 2014, at 10:48 AM, Brad King  wrote:

> On 09/30/2014 10:14 AM, Williams, Norman K wrote:
>> find_package(VTK REQUIRED)
>> find_package(ITK REQUIRED)
>> 
>> You can’t real compile anything that needs VTK, because down in
>> the ITK deployment stuff, it calls find_package(VTK) like this:
> [snip]
>> Which blows away the larger list of include directories and libraries
> 
> One may use the itk_module_config and vtk_module_config macros
> from the *ModuleAPI.cmake modules that come with the respective
> packages to compute the list of libraries and include dirs for
> a given list of components.  All ITKConfig and VTKConfig do with
> the list of components is:
> 
> itk_module_config(ITK ${ITK_MODULES_REQUESTED})
> # sets ITK_LIBRARIES, ITK_INCLUDE_DIRS, etc.
> 
> and
> 
> vtk_module_config(VTK ${VTK_MODULES_REQUESTED})
> # sets VTK_LIBRARIES, VTK_INCLUDE_DIRS, etc.
> 
> One can invoke these directly:
> 
> itk_module_config(ITK ${MY_LIST_OF_ITK_COMPONENTS})
> vtk_module_config(VTK ${MY_LIST_OF_VTK_COMPONENTS})
> 
> at any time after the find_package calls.  One could even use
> a different prefix:
> 
> itk_module_config(MyITK ${MY_LIST_OF_ITK_COMPONENTS})
> # sets MyITK_LIBRARIES, MyITK_INCLUDE_DIRS, etc.
> 
> In the long run the plan is to stop recommending use of component
> lists at find_package time and instead use imported targets and
> usage requirements:
> 
> http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#build-specification-and-usage-requirements
> 
> but that will have to wait until we can require CMake 3.0.
> 
> -Brad
> 
> ___
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> 
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
> 
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/insight-developers

-- 

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


Re: [CMake] [ITK-dev] find_package issues with ITK and VTK (and SlicerExecution Model)

2014-09-30 Thread Brad King
On 09/30/2014 10:14 AM, Williams, Norman K wrote:
> find_package(VTK REQUIRED)
> find_package(ITK REQUIRED)
> 
> You can’t real compile anything that needs VTK, because down in
> the ITK deployment stuff, it calls find_package(VTK) like this:
[snip]
> Which blows away the larger list of include directories and libraries

One may use the itk_module_config and vtk_module_config macros
from the *ModuleAPI.cmake modules that come with the respective
packages to compute the list of libraries and include dirs for
a given list of components.  All ITKConfig and VTKConfig do with
the list of components is:

 itk_module_config(ITK ${ITK_MODULES_REQUESTED})
 # sets ITK_LIBRARIES, ITK_INCLUDE_DIRS, etc.

and

 vtk_module_config(VTK ${VTK_MODULES_REQUESTED})
 # sets VTK_LIBRARIES, VTK_INCLUDE_DIRS, etc.

One can invoke these directly:

 itk_module_config(ITK ${MY_LIST_OF_ITK_COMPONENTS})
 vtk_module_config(VTK ${MY_LIST_OF_VTK_COMPONENTS})

at any time after the find_package calls.  One could even use
a different prefix:

 itk_module_config(MyITK ${MY_LIST_OF_ITK_COMPONENTS})
 # sets MyITK_LIBRARIES, MyITK_INCLUDE_DIRS, etc.

In the long run the plan is to stop recommending use of component
lists at find_package time and instead use imported targets and
usage requirements:

 
http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#build-specification-and-usage-requirements

but that will have to wait until we can require CMake 3.0.

-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


Re: [CMake] [ITK-dev] find_package issues with ITK and VTK (and SlicerExecution Model)

2014-09-30 Thread Bill Lorensen
Here is what I do for the WikiExamples remote module:
find_package(VTK REQUIRED)
  include(${VTK_USE_FILE})
  set(VTK_COMPONENTS ${VTK_LIBRARIES})

  find_package(ITK REQUIRED)
  include(${ITK_USE_FILE})
  set(ITK_LIBRARIES ${ITK_LIBRARIES} ${VTK_COMPONENTS})


On Tue, Sep 30, 2014 at 10:14 AM, Williams, Norman K
 wrote:
> This is a problem that has been cropping up in our projects that use ITK,
> VTK and SlicerExecutionModel.
>
> You won’t see it UNLESS you turn on the ITKVTK/ITKVtkGlue modules.
>
> The problem is this: if you find packages in this order:
>
> find_package(VTK REQUIRED)
> find_package(ITK REQUIRED)
>
> You can’t real compile anything that needs VTK, because down in the ITK
> deployment stuff, it calls find_package(VTK) like this:
> find_package(VTK COMPONENTS
>   vtkCommonCore
>   vtkRenderingCore
>   vtkRenderingOpenGL
>   vtkRenderingFreeType
>   vtkInteractionStyle
>   vtkIOImage
>   vtkImagingSources
>   REQUIRED)
>
> Which blows away the larger list of include directories and libraries that
> the first find_package(VTK REQUIRED) built.
>
> Even better — or worse —
> Modules/Segmentation/LevelSetsv4Visualization/CMakeLists.txt also include
> find_package(VTK) — so ITK tries to import VTK twice, with different module
> lists.
>
> It doesn’t even help to reverse the order:
> find_package(ITK REQUIRED)
> find_package(VTK REQUIRED)
>
> because apparently there’s some hangover from the find_package(VTK) inside
> the ITK CMake deployment files.  The only thing that works is to use
> COMPONENTS, i.e.
>
> find_package(ITK REQUIRED)
> find_package(VTK COMPONENTS vtkCommonCore vtkRenderingAnnotation … REQUIRED)
>
> Which seems to trigger a proper re-scan and build of the library/include
> lists.
>
> It gets even worse if you use find_package(SlicerExecutionModel) after
> find_package(ITK), for the same reason — SlicerExecutionModel depends on
> ITK, so it clobbers the include/library lists from the first
> find_package(ITK).
>
>
>
>
> 
> Notice: This UI Health Care e-mail (including attachments) is covered by the
> Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential
> and may be legally privileged.  If you are not the intended recipient, you
> are hereby notified that any retention, dissemination, distribution, or
> copying of this communication is strictly prohibited.  Please reply to the
> sender that you have received the message in error, then delete it.  Thank
> you.
> 
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/insight-developers
>



-- 
Unpaid intern in BillsBasement at noware dot 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

[CMake] find_package issues with ITK and VTK (and SlicerExecution Model)

2014-09-30 Thread Williams, Norman K
This is a problem that has been cropping up in our projects that use ITK, VTK 
and SlicerExecutionModel.

You won’t see it UNLESS you turn on the ITKVTK/ITKVtkGlue modules.

The problem is this: if you find packages in this order:

find_package(VTK REQUIRED)
find_package(ITK REQUIRED)

You can’t real compile anything that needs VTK, because down in the ITK 
deployment stuff, it calls find_package(VTK) like this:
find_package(VTK COMPONENTS
  vtkCommonCore
  vtkRenderingCore
  vtkRenderingOpenGL
  vtkRenderingFreeType
  vtkInteractionStyle
  vtkIOImage
  vtkImagingSources
  REQUIRED)

Which blows away the larger list of include directories and libraries that the 
first find_package(VTK REQUIRED) built.

Even better — or worse — 
Modules/Segmentation/LevelSetsv4Visualization/CMakeLists.txt also include 
find_package(VTK) — so ITK tries to import VTK twice, with different module 
lists.

It doesn’t even help to reverse the order:
find_package(ITK REQUIRED)
find_package(VTK REQUIRED)

because apparently there’s some hangover from the find_package(VTK) inside the 
ITK CMake deployment files.  The only thing that works is to use COMPONENTS, 
i.e.

find_package(ITK REQUIRED)
find_package(VTK COMPONENTS vtkCommonCore vtkRenderingAnnotation … REQUIRED)

Which seems to trigger a proper re-scan and build of the library/include lists.

It gets even worse if you use find_package(SlicerExecutionModel) after 
find_package(ITK), for the same reason — SlicerExecutionModel depends on ITK, 
so it clobbers the include/library lists from the first find_package(ITK).





Notice: This UI Health Care e-mail (including attachments) is covered by the 
Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and 
may be legally privileged.  If you are not the intended recipient, you are 
hereby notified that any retention, dissemination, distribution, or copying of 
this communication is strictly prohibited.  Please reply to the sender that you 
have received the message in error, then delete it.  Thank you.

-- 

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

Re: [CMake] INTERFACE_LINK_LIBRARIES and CMP0028

2014-09-30 Thread Nils Gladitz

On 09/30/2014 09:58 AM, Mueller-Roemer, Johannes Sebastian wrote:

The behavior of the transitive INTERFACE_LINK_LIBRARIES combined with
CMP0028 seems very broken to me. For libraries using a module (such as
ZLIB), I can simply do a find_package in one of my libraries’
CMakeLists.txt and link to it in a different CMakeLists.txt without
issues. If I do the same with libraries using configs and IMPORTED
targets (such as Qt5), I cannot have my find_package at the place of use
but am forced to move it to the root CMakeLists.txt as I otherwise get
CMP0028 warnings. Is this actually intended behavior? Am I doing
something wrong? Shouldn’t INTERFACE_LINK_LIBRARIES just include the
actual libraries (and INTERFACE_INCLUDE_DIRECTORIES the actual include
directories) when linking to an imported target. These extra
dependencies between CMakeLists.txt are very ugly :/


If I understand correctly then this was fixed here:

http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a272344228174958a8b2346793d3272eb432dad8

Which should be in 3.1 when it is released.

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


[CMake] INTERFACE_LINK_LIBRARIES and CMP0028

2014-09-30 Thread Mueller-Roemer, Johannes Sebastian
The behavior of the transitive INTERFACE_LINK_LIBRARIES combined with CMP0028 
seems very broken to me. For libraries using a module (such as ZLIB), I can 
simply do a find_package in one of my libraries' CMakeLists.txt and link to it 
in a different CMakeLists.txt without issues. If I do the same with libraries 
using configs and IMPORTED targets (such as Qt5), I cannot have my find_package 
at the place of use but am forced to move it to the root CMakeLists.txt as I 
otherwise get CMP0028 warnings. Is this actually intended behavior? Am I doing 
something wrong? Shouldn't INTERFACE_LINK_LIBRARIES just include the actual 
libraries (and INTERFACE_INCLUDE_DIRECTORIES the actual include directories) 
when linking to an imported target. These extra dependencies between 
CMakeLists.txt are very ugly :/

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de  |  www.igd.fraunhofer.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

Re: [CMake] Issues setting CMAKE_VS_PLATFORM_TOOLSET

2014-09-30 Thread J Decker
On Tue, Sep 30, 2014 at 12:15 AM, Nils Gladitz 
wrote:

> On 09/30/2014 09:02 AM, J Decker wrote:
>
>> I was recently trying to package some apps I was building, but ran into
>> an issue that they weren't compatible on XP.  ... I was setting
>> CMAKE_VS_PLATFORM_TOOLSET on the base SDK but that wasn't being relayed
>> to subsequent projects... so I fixed that, and the toolset still isn't
>> being set.
>>
>
> To set the platform toolset try -T  from the cmake command line.
>
> From what I can tell CMAKE_VS_PLATFORM_TOOLSET isn't meant to be set by
> the user but should reflect what you set with -T.
>
> okay... -T works; that complicates the chained-build though
would be nice if I can just pick up and use the variable that was used for
core projects. *shrug*


> 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

Re: [CMake] Issues setting CMAKE_VS_PLATFORM_TOOLSET

2014-09-30 Thread Nils Gladitz

On 09/30/2014 09:02 AM, J Decker wrote:

I was recently trying to package some apps I was building, but ran into
an issue that they weren't compatible on XP.  ... I was setting
CMAKE_VS_PLATFORM_TOOLSET on the base SDK but that wasn't being relayed
to subsequent projects... so I fixed that, and the toolset still isn't
being set.


To set the platform toolset try -T  from the cmake command line.

From what I can tell CMAKE_VS_PLATFORM_TOOLSET isn't meant to be set by 
the user but should reflect what you set with -T.


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


[CMake] Issues setting CMAKE_VS_PLATFORM_TOOLSET

2014-09-30 Thread J Decker
I was recently trying to package some apps I was building, but ran into an
issue that they weren't compatible on XP.  ... I was setting
CMAKE_VS_PLATFORM_TOOLSET on the base SDK but that wasn't being relayed to
subsequent projects... so I fixed that, and the toolset still isn't being
set.

This is a clip from "cmake --trace "

I added a message() to log what the toolset was set to in
cmakedeterminecompilerid.cmake...  Even though it's set earlier to v110_xp,
when it uses the value later it is only 'v110'

I don't understand where it is getting reset... in the 'cut'
section there are no references to that variable...
I'm using a nightly build  3.0.20140924-g8abd5 from about a week ago
---

Running with trace output on.
/General/Build/sack/debug_out/core/CMakePackage(7):  message(SET
CMAKE_VS_PLATFORM_TOOLSET )
SET CMAKE_VS_PLATFORM_TOOLSET
/General/Build/sack/debug_out/core/CMakePackage(8):
 set(CMAKE_VS_PLATFORM_TOOLSET v110_xp )
/General/Build/sack/debug_out/core/CMakePackage(9):
 add_definitions(-wd4996 )
/General/Build/sack/debug_out/core/CMakePackage(11):  enable_language(C )
 cut
c:/tools/unix/cmake/share/cmake-3.0/Modules/CMakeDetermineCompilerId.cmake(142):
 set(id_platform ${CMAKE_VS_PLATFORM_NAME} )
c:/tools/unix/cmake/share/cmake-3.0/Modules/CMakeDetermineCompilerId.cmake(143):
 set(id_lang ${lang} )
c:/tools/unix/cmake/share/cmake-3.0/Modules/CMakeDetermineCompilerId.cmake(144):
 set(id_cl cl.exe )
c:/tools/unix/cmake/share/cmake-3.0/Modules/CMakeDetermineCompilerId.cmake(145):
 if(CMAKE_VS_PLATFORM_NAME STREQUAL Tegra-Android )
c:/tools/unix/cmake/share/cmake-3.0/Modules/CMakeDetermineCompilerId.cmake(155):
 elseif(lang STREQUAL Fortran )
c:/tools/unix/cmake/share/cmake-3.0/Modules/CMakeDetermineCompilerId.cmake(159):
 elseif(NOT ${vs_version} VERSION_LESS 10 )
c:/tools/unix/cmake/share/cmake-3.0/Modules/CMakeDetermineCompilerId.cmake(160):
 set(v 10 )
c:/tools/unix/cmake/share/cmake-3.0/Modules/CMakeDetermineCompilerId.cmake(161):
 set(ext vcxproj )
c:/tools/unix/cmake/share/cmake-3.0/Modules/CMakeDetermineCompilerId.cmake(170):
 if(${id_platform} STREQUAL Itanium )
c:/tools/unix/cmake/share/cmake-3.0/Modules/CMakeDetermineCompilerId.cmake(173):
 message(CMAKE_VS_PLATFORM_TOOLSET ${CMAKE_VS_PLATFORM_TOOLSET} )
CMAKE_VS_PLATFORM_TOOLSET v110
c:/tools/unix/cmake/share/cmake-3.0/Modules/CMakeDetermineCompilerId.cmake(174):
 if(CMAKE_VS_PLATFORM_TOOLSET )
c:/tools/unix/cmake/share/cmake-3.0/Modules/CMakeDetermineCompilerId.cmake(175):
 if(CMAKE_VS_PLATFORM_NAME STREQUAL Tegra-Android )
c:/tools/unix/cmake/share/cmake-3.0/Modules/CMakeDetermineCompilerId.cmake(177):
 else()
c:/tools/unix/cmake/share/cmake-3.0/Modules/CMakeDetermineCompilerId.cmake(178):
 set(id_toolset
${CMAKE_VS_PLATFORM_TOOLSET} )
-- 

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