[cmake-developers] [CMake 0016111]: Memory leak during function call

2016-05-25 Thread Mantis Bug Tracker 

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=16111 
== 
Reported By:Sergey
Assigned To:
== 
Project:CMake
Issue ID:   16111
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-05-26 02:39 EDT
Last Modified:  2016-05-26 02:39 EDT
== 
Summary:Memory leak during function call
Description: 
There is a memory leak during function call if function contains any
if/else/endif statement.

Steps to Reproduce: 
• Create simple CMakeLists.txt with next content:

cmake_minimum_required(VERSION 3.5)

project (MyTestProject)

function (test_memory_leak)
  if(ON)
  endif()
endfunction()

while(ON)
  test_memory_leak()
endwhile()

• Run cmake-gui.exe
• Try to configure the project

Result: cmake-gui.exe will crash with out of memory (can be seen in Task
Manager)
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-05-26 02:39 Sergey New Issue
==

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake 0016110]: LINK_LIBRARIES contains both libraries and flags, separate variables required

2016-05-25 Thread Mantis Bug Tracker 

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=16110 
== 
Reported By:Roman Popov
Assigned To:
== 
Project:CMake
Issue ID:   16110
Category:   CMake
Reproducibility:always
Severity:   feature
Priority:   normal
Status: new
== 
Date Submitted: 2016-05-25 18:46 EDT
Last Modified:  2016-05-25 18:46 EDT
== 
Summary:LINK_LIBRARIES contains both libraries and flags, 
separate variables required
Description: 
For example, if I write my own link rule:
set(CMAKE_CXX_LINK_EXECUTABLE "echo \"  \" ")  LINK_LIBRARIES
will evaluate to : 
- flags (like: -rdynamic -Wl,-rpath,rpath1:rpath2 ...)
- static libraries (like: lib1.a -lthreads ...) 
- dynamic libraries (like: libdlib.so )

To support new gcc-compatible linking tools (for example  Synopsys VCS or
Cadence NCSIM ) flags and libs need to be separated: for example into some new
variables: LINK_LIBRARIES_FLAGS , LINK_LIBRARIES_STATIC, LINK_LIBRARIES_SHARED.

In that case user can simply define new linking rules, for example:
(CMAKE_CXX_LINK_EXECUTABLE "vcs -sysc -LDFLAGS \"  \"
   ")
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-05-25 18:46 Roman PopovNew Issue
==

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake 0016109]: Downloading of a file may hang indefinitely with ExternalProject

2016-05-25 Thread Mantis Bug Tracker 

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=16109 
== 
Reported By:Ilya
Assigned To:
== 
Project:CMake
Issue ID:   16109
Category:   CMake
Reproducibility:sometimes
Severity:   tweak
Priority:   normal
Status: new
== 
Date Submitted: 2016-05-25 16:08 EDT
Last Modified:  2016-05-25 16:08 EDT
== 
Summary:Downloading of a file may hang indefinitely with
ExternalProject
Description: 
The `file(DOWNLOAD` command used by ExternalProject is not limited by any
timeouts.

It should, instead, automatically retry (and possibly continue) to download the
file.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-05-25 16:08 Ilya   New Issue
==

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Problem with find_path and Frameworks

2016-05-25 Thread Eric Wing 
On 5/25/16, Harry Mallon  wrote:
> I have quite a specific problem with find_path where
> "find_path(IOKIT_INCLUDE_DIR "IOKit/pci/IOPCIDevice.h")" returns
> "/System/Library/Frameworks/Kernel.framework/Headers/IOKit/pci" rather than
> "/System/Library/Frameworks/Kernel.framework/Headers/".
>
> It is reproducible on OSX with the following CMakeLists.txt:
>
> cmake_minimum_required(VERSION 3.0)
> find_path(IOKIT_INCLUDE_DIR "IOKit/pci/IOPCIDevice.h")
> message("Path returned: ${IOKIT_INCLUDE_DIR}")
>
> Here is a patch which seems to fix it for me:
>

This is a pretty atypical situation. I’m actually not sure what the
behavior should be. But we need to be careful to not break the
existing cases. I’m a little worried that there may be things out
there relying on the existing behavior. I’m also not convinced this
actually needs a patch.


The framework header path system was hammered out over a long period
of time. There are two common use cases that it was designed to
handle:

case 1: #import 
find_path(COCOA_INCLUDE_DIR “Cocoa/Cocoa.h”)
# Returns something like /System/Library/Frameworks/Cocoa.framework


case 2: #include “al.h”
find_path(OPENAL_INCLUDE_DIR “al.h”)
# Returns something like /System/Library/Frameworks/OpenAL.framework/Headers


The reason for this behavior is that unlike other platforms,
frameworks are not a direct mapping to file system mapping. When
dealing with official Apple frameworks, you are expected to use case
1. But  the second form is an important concession for cross-platform
libraries. The problem is that many libraries, especially 3rd party
libraries, do not end up in subdirectories with the same names on all
platforms.

For OpenGL, most Unix’s do , but Apple does .
For OpenAL, it is crazier because it depends on which implementation
you use. Apple does , OpenAL Soft does , but
others have presumes no subdirectory at all.
And a lot of third party libraries don’t have any official
conventions, so distributions do everything differently. So for
cross-platform, you are encouraged to do “Foo.h” omitting a path and
letting the build system deal with it (since CMake can do a better job
here than a massive, hand-coded mess of #ifdefs in your files.


So your case seems very atypical because you are using something
inside Kernel.framework and the header you want is not in
IOKit.framework. If it was a more typical scenario like
IOKit.framework,

I would kind of expect you to find a file in IOKit at the top level
instead to represent all your IOKit dealings, e.g.

find_path(IOKIT_INCLUDE_DIR “IOKit/IOKitLib.h”)

Then in your code you would do:
#import , and what you get back from CMake
(/System/Library/Frameworks/IOKit.framework) would be correct.

But since pci doesn’t actually seem to be directly in IOKit, but
instead the Kernel.framework subdirectory mess, I’m not sure what the
appropriate thing is. The normal native Xcode header path search
mechanism doesn’t seem to support this case and I found an old mailing
list thread suggesting that this is Apple’s way of telling you to
keep-out.


I would actually be inclined to suggest a much more generic find for
Kernel.framework and build your paths manually from there.


So either something simple like:
find_path(KERNEL_INCLUDE_DIR IOKit)
# return /System/Library/Frameworks/Kernel.framework/Headers


Or something a little more defensive to avoid possible name
collisions, but requires manual construction:
find_path(KERNEL_INCLUDE_DIR Kernel/IOKit)
# return /System/Library/Frameworks/Kernel.framework
set(KERNEL_IOKIT_INCLUDE_DIR “${KERNEL_INCLUDE_DIR}/Headers”)


-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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake 3.5.2 conflates OSX SDK version with target deployment

2016-05-25 Thread clinton 


- On May 25, 2016, at 12:38 PM, Brad King brad.k...@kitware.com wrote:

> On 05/25/2016 02:31 PM, Sean McBride wrote:
>> CMake should probably default to the newest SDK (which is what Xcode does).
>> I don't see a reason to default to an SDK "matching" the deployment target,
>> in fact it's problematic these days since they no longer provider older SDKs.
>> 
>> Of course, finding the "newest" SDK will be a bit fragile, since they get
>> moved/renamed all the time, but I guess that's something CMake always has to
>> deal with anyway.
> 
> This is all worked out in Modules/Platform/Darwin-Initialize.cmake:
> 
>  
> https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Darwin-Initialize.cmake;hb=v3.5.2#l38
> 
> The logic there has evolved over the years and is pretty solid now.
> It has good default behavior, and anyone that really needs a specific
> combination can specify it themselves explicitly.
> 
> The only question in this thread is whether the warning about the SDK
> and deployment target version not matching exactly is ever useful:
> 
> https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Darwin-Initialize.cmake;hb=v3.5.2#l97
> 
> Note that this is separate from the version compatibility check here:
> 
> https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Darwin.cmake;hb=v3.5.2#l67
> 
> which is an error.
> 
> -Brad

I don't think we need the warning.
A different version for deployment target and SDK is common.

Here
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Darwin-Initialize.cmake;hb=v3.5.2#l81
the found SDK is equal or newer to the deployment target, which is good.

Clint
-- 

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] CMake 3.5.2 conflates OSX SDK version with target deployment

2016-05-25 Thread Brad King 
On 05/25/2016 02:31 PM, Sean McBride wrote:
> CMake should probably default to the newest SDK (which is what Xcode does).
> I don't see a reason to default to an SDK "matching" the deployment target,
> in fact it's problematic these days since they no longer provider older SDKs.
> 
> Of course, finding the "newest" SDK will be a bit fragile, since they get
> moved/renamed all the time, but I guess that's something CMake always has to
> deal with anyway.

This is all worked out in Modules/Platform/Darwin-Initialize.cmake:

  
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Darwin-Initialize.cmake;hb=v3.5.2#l38

The logic there has evolved over the years and is pretty solid now.
It has good default behavior, and anyone that really needs a specific
combination can specify it themselves explicitly.

The only question in this thread is whether the warning about the SDK
and deployment target version not matching exactly is ever useful:

 
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Darwin-Initialize.cmake;hb=v3.5.2#l97

Note that this is separate from the version compatibility check here:

 
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Darwin.cmake;hb=v3.5.2#l67

which is an error.

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake 3.5.2 conflates OSX SDK version with target deployment

2016-05-25 Thread Sean McBride 
On Sat, 21 May 2016 22:50:41 -0700, James Burgess said:

>If your set CMAKE_OSX_DEPLOYMENT_TARGET in order to get find modules to
>work on Xcode6 or above you get this message:
>
>$ cmake -D CMAKE_OSX_DEPLOYMENT_TARGET=10.8 .
>  CMAKE_OSX_DEPLOYMENT_TARGET is '10.8' but the matching SDK does not exist
>  at:
>
>   "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/
>Developer/SDKs/MacOSX10.8.sdk"
>
>  Instead using SDK:
>
>   "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/
>Developer/SDKs/MacOSX10.10.sdk".
>Call Stack (most recent call first):
>  /Applications/CMake.app/Contents/share/cmake-3.5/Modules/
>CMakeSystemSpecificInitialize.cmake:18 (include)
>  CMakeLists.txt:25 (project)

It seems to me that if you're going to specify a deployment target explicitly 
that you should specify an SDK explicitly too.

That aside, if you don't, CMake should probably default to the newest SDK 
(which is what Xcode does).  I don't see a reason to default to an SDK 
"matching" the deployment target, in fact it's problematic these days since 
they no longer provider older SDKs.

Of course, finding the "newest" SDK will be a bit fragile, since they get 
moved/renamed all the time, but I guess that's something CMake always has to 
deal with anyway.

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada


-- 

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] Problem with find_path and Frameworks

2016-05-25 Thread Brad King 
On 05/25/2016 01:25 PM, Harry Mallon wrote:
> I have quite a specific problem with find_path where 
> "find_path(IOKIT_INCLUDE_DIR "IOKit/pci/IOPCIDevice.h")"
> returns "/System/Library/Frameworks/Kernel.framework/Headers/IOKit/pci" 
> rather than
> "/System/Library/Frameworks/Kernel.framework/Headers/".

Thanks.  Please extend the Tests/RunCMake/find_path test to cover
this behavior.  You could add a bogus framework layout inside the
test source tree.  See Tests/RunCMake/README.rst for details of
the test infrastructure.

> +while (*fullPart++ == *relPart++)

I think the logic can be simpler.

The intended logic here is to get back up to the ".framework/Headers"
directory.  Since the glob we use always appends exactly the original
file name after this, we can just clip off the matching number of
characters from the result.  Or, just search for the last occurrence
of ".framework/Headers/" and clip off there.

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Problem with find_path and Frameworks

2016-05-25 Thread Harry Mallon 
I have quite a specific problem with find_path where 
"find_path(IOKIT_INCLUDE_DIR "IOKit/pci/IOPCIDevice.h")" returns 
"/System/Library/Frameworks/Kernel.framework/Headers/IOKit/pci" rather than 
"/System/Library/Frameworks/Kernel.framework/Headers/".

It is reproducible on OSX with the following CMakeLists.txt:

cmake_minimum_required(VERSION 3.0)
find_path(IOKIT_INCLUDE_DIR "IOKit/pci/IOPCIDevice.h")
message("Path returned: ${IOKIT_INCLUDE_DIR}")

Here is a patch which seems to fix it for me:


Harry Mallon
CODEX | Software Engineer
60 Poland Street | London | England | W1F 7NT
E ha...@codexdigital.com | T +44 203 7000 989


0001-Fix-a-problem-where-using-find_path-to-find-a-header.patch
Description: 0001-Fix-a-problem-where-using-find_path-to-find-a-header.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] Optionally disable /Applications symlink in CPack dragndrop generator

2016-05-25 Thread Brad King 
On 05/25/2016 08:46 AM, Harry Mallon wrote:
> Pull request to optionally disable the /Applications symlink.

Thanks, applied with minor tweaks:

 CPack/DragNDrop: Optionally disable `/Applications` symlink
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3acc29fc

-Brad
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [Patch] Updated FindMatlab.cmake for Matlab R2016a

2016-05-25 Thread Brad King 
On 05/25/2016 03:50 AM, Francesco Romano wrote:
> Added check of Matlab 2016a (9.0) to FindMatlab.cmake

Thanks, applied:

 FindMatlab: Add support for Matlab 2016a (9.0)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=715e4cf5

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Optionally disable /Applications symlink in CPack dragndrop generator

2016-05-25 Thread Harry Mallon 
Pull request to optionally disable the /Applications symlink. It is useful when 
distributing .app files but not needed when distributing other things.
https://github.com/Kitware/CMake/pull/246

Harry

Harry Mallon

CODEX | Software Engineer

60 Poland Street | London | England | W1F 7NT

E ha...@codexdigital.com | T +44 203 7000 
989

Website | Facebook 
| Twitter

[http://www.codexdigital.com/?action=asset&id=E55D8A6F-AF62-4978-8FF1-435A85AFADBF]
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake 0016108]: get_prerequisites failed to locate installed Microsoft Visual Studio if installed into not default location

2016-05-25 Thread Mantis Bug Tracker 

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=16108 
== 
Reported By:Andry81
Assigned To:
== 
Project:CMake
Issue ID:   16108
Category:   CPack
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-05-25 08:22 EDT
Last Modified:  2016-05-25 08:22 EDT
== 
Summary:get_prerequisites failed to locate installed
Microsoft Visual Studio if installed into not default location
Description: 
get_prerequisites could not find dumpbin.exe and has tried to use unexisted
objdump.exe

Reason: get_prerequisites (share/cmake-3.5/Modules/GetPrerequisites.cmake) does
search Microsoft Visual Studio incorrectly

Steps to Reproduce: 
1. make sure that all versions of Microsoft Visual Studio has installed into not
default locations

2. run cpack after cmake in the cmake build directory:
>cmake .
>cmake --build . --config release
>cpack -V --config CPackConfig.cmake .

3. observe messages "CPack Verbose: warning: could not find 'objdump' - cannot
analyze prerequisites..."

Additional Information: 
To fix it replace this in the "share/cmake-3.5/Modules/GetPrerequisites.cmake"
file:
  set(gp_cmd_paths ${gp_cmd_paths}
"C:/Program Files/Microsoft Visual Studio 9.0/VC/bin"
"C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/bin"
"C:/Program Files/Microsoft Visual Studio 8/VC/BIN"
"C:/Program Files (x86)/Microsoft Visual Studio 8/VC/BIN"
"C:/Program Files/Microsoft Visual Studio .NET 2003/VC7/BIN"
"C:/Program Files (x86)/Microsoft Visual Studio .NET 2003/VC7/BIN"
"/usr/local/bin"
"/usr/bin"
)

To something like this:
  set(gp_cmd_paths ${gp_cmd_paths}
   
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\14.0;InstallDir]/../../VC/bin
   
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\12.0;InstallDir]/../../VC/bin
   
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\11.0;InstallDir]/../../VC/bin
   
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\10.0;InstallDir]/../../VC/bin
   
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\9.0;InstallDir]/../../VC/bin
   
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\8.0;InstallDir]/../../VC/bin
   
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\7.1;InstallDir]/../../VC7/bin
   
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\VisualStudio\\14.0;InstallDir]/../../VC/bin
   
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\VisualStudio\\12.0;InstallDir]/../../VC/bin
   
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\VisualStudio\\11.0;InstallDir]/../../VC/bin
   
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\VisualStudio\\10.0;InstallDir]/../../VC/bin
   
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\VisualStudio\\9.0;InstallDir]/../../VC/bin
   
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\VisualStudio\\8.0;InstallDir]/../../VC/bin
   
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\VisualStudio\\7.1;InstallDir]/../../VC7/bin
"C:/Program Files/Microsoft Visual Studio 9.0/VC/bin"
"C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/bin"
"C:/Program Files/Microsoft Visual Studio 8/VC/BIN"
"C:/Program Files (x86)/Microsoft Visual Studio 8/VC/BIN"
"C:/Program Files/Microsoft Visual Studio .NET 2003/VC7/BIN"
"C:/Program Files (x86)/Microsoft Visual Studio .NET 2003/VC7/BIN"
"/usr/local/bin"
"/usr/bin"
)

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-05-25 08:22 Andry81New Issue
==

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [Patch] Updated FindMatlab.cmake for Matlab R2016a

2016-05-25 Thread Francesco Romano 
Added check of Matlab 2016a (9.0) to FindMatlab.cmake





0001-FindMatlab.cmake-Added-support-to-Matlab-2016a-9.0.patch
Description: Binary data
-- 

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