Re: [cmake-developers] nvidia nsight tegra set vcxproj properties (Ant Build) in cmake file

2015-08-27 Thread Peter List
A related but different issue...  I tried adding this to my CMakeLists.txt:

set(CMAKE_ANDROID_NATIVE_LIB_DEPENDENCIES zzz)
set(CMAKE_ANDROID_NATIVE_LIB_DIRECTORIES yyy)

But cmake 3.1.1 release does not add the expected properties to my
vcxproj.  In fact, the strings "zzz" and "yyy" are not found in my vcxproj
file.

So I tried a nightly build, but I got a different error - full text pasted
below

Looks like cmake is doing some sanity check by building a simple test
program, but link fails with cannot find -l-Wl,-Bdynamic.

Maybe "cmake-3.3.20150826-g566f1-win32-x86" isn't ready yet?

Btw I'm using AndroidWorks-1R2-win.exe
+ NVIDIA_Nsight_Tegra_Release_3.1.15202.6244.exe, so another guess is that
maybe it's a compatibility issue...  Like I have to use a particular
version of nsight with a particular version of cmake

thank you for any leads,
Peter

...
...
...

> "C:\Program Files (x86)\cmake-3.3.20150826-g566f1-win32-x86\bin\cmake"
-G"Visual Studio 10 2010" -DCMAKE_SYSTEM_NAME="Android"  ..\pemDemos

-- The C compiler identification is GNU 4.9.0
-- The CXX compiler identification is GNU 4.9.0
-- Check for working C compiler using: Visual Studio 10 2010
-- Check for working C compiler using: Visual Studio 10 2010 -- broken
CMake Error at C:/Program Files
(x86)/cmake-3.3.20150826-g566f1-win32-x86/share/cmake-3.3/Modules/CMakeTestCCompiler.cmake:61
(message):
  The C compiler

"C:/Programs/NVPACK/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/arm-linux-androideabi-gcc.exe"
  is not able to compile a simple test program.
  It fails with the following output:
   Change Dir:
H:/Pem_Code/grfxdemossdl2015/pemDemos/build-android-vs2010/CMakeFiles/CMakeTmp
  Run Build
  Command:"C:/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe"
  "cmTC_84fb1.vcxproj" "/p:Configuration=Debug"
"/p:VisualStudioVersion=10.0"
  Microsoft (R) Build Engine version 4.6.79.0
  [Microsoft .NET Framework, version 4.0.30319.42000]
  Copyright (C) Microsoft Corporation.  All rights reserved.
  Build started 8/28/2015 12:35:31 AM.

  Project

"H:\Pem_Code\grfxdemossdl2015\pemDemos\build-android-vs2010\CMakeFiles\CMakeTmp\cmTC_84fb1.vcxproj"
  on node 1 (default targets).

  PrepareForBuild:

Creating directory "cmTC_84fb1.dir\Debug\".
Creating directory
"H:\Pem_Code\grfxdemossdl2015\pemDemos\build-android-vs2010\CMakeFiles\CMakeTmp\Debug\".

  InitializeBuildStatus:

Creating "cmTC_84fb1.dir\Debug\cmTC_84fb1.unsuccessfulbuild" because
"AlwaysCreate" was specified.

  ClCompile:


C:\Programs\NVPACK\android-ndk-r10e\toolchains\arm-linux-androideabi-4.9\prebuilt\windows-x86_64\bin\arm-linux-androideabi-g++.exe
testCCompiler.c

  C:\Program Files
  (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(991,5):
warning
  MSB8012: TargetExt(.) does not match the Linker's OutputFile property
value
  ().  This may cause your project to build incorrectly.  To correct this,
  please make sure that $(OutDir), $(TargetName) and $(TargetExt) property
  values match the value specified in %(Link.OutputFile).

[H:\Pem_Code\grfxdemossdl2015\pemDemos\build-android-vs2010\CMakeFiles\CMakeTmp\cmTC_84fb1.vcxproj]


  Link:


C:\Programs\NVPACK\android-ndk-r10e\toolchains\arm-linux-androideabi-4.9\prebuilt\windows-x86_64\bin\arm-linux-androideabi-g++.exe
cmTC_84fb1.dir
Debug/testCCompiler.o  -Wl,-soname,cmTC_84fb1. -shared
--sysroot=C:/Programs/NVPACK/android-ndk-r10e/platforms/android-9/arch-arm
-Wl,-rpath-link=C:/
rograms/NVPACK/android-ndk-r10e/platforms/android-9/arch-arm/usr/lib
"-l-Wl,-Bdynamic" -fuse-ld=bfd -Wl,--no-undefined -Wl,-z,noexecstack
-Wl,-z,relr
 -Wl,-z,now
-L"C:/Programs/NVPACK/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/lib/gcc/arm-linux-androideabi/4.9/arm
7-a"
-L"C:/Programs/NVPACK/android-ndk-r10e/platforms/android-9/arch-arm/usr/lib"
-L"C:/Programs/NVPACK/android-ndk-r10e/sources/cxx-stl/gnu-libstdc+
/4.9/libs/armeabi-v7a"
-L"C:/Programs/NVPACK/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/lib/gcc/arm-linux-androide
bi/4.9/armv7-a"
"C:/Programs/NVPACK/android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/libgnustl_static.a"
-lc -lm -llog -lgcc -oH:/
em_Code/grfxdemossdl2015/pemDemos/build-android-vs2010/CMakeFiles/CMakeTmp/Debug/cmTC_84fb1.

c:/programs/nvpack/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.9/../../.
/../arm-linux-androideabi/bin/ld.bfd.exe: cannot find -l-Wl,-Bdynamic

  collect2.exe : error : ld returned 1 exit status

[H:\Pem_Code\grfxdemossdl2015\pemDemos\build-android-vs2010\CMakeFiles\CMakeTmp\cmTC_84fb1.vcxproj]


  Done Building Project

"H:\Pem_Code\grfxdemossdl2015\pemDemos\build-android-vs2010\CMakeFiles\CMakeTmp\cmTC_84fb1.vcxproj"
  (default targets) -- FAILED.



  Build FAILED.





"H:\Pem_Code\grfxdemossdl2015\pemDemos\build-android-vs2010\CMakeFiles\CMakeTmp\cmTC_84fb1.vcxproj"
  (default target)

Re: [cmake-developers] nvidia nsight tegra set vcxproj properties (Ant Build) in cmake file

2015-08-27 Thread Peter List
vs2010 works for my CMakeLists.txt:

> cmake -G"Visual Studio 10 2010" -DCMAKE_SYSTEM_NAME="Android"  ..\pemDemos
-- The C compiler identification is GNU 4.9.0
-- The CXX compiler identification is GNU 4.9.0
-- Check for working C compiler using: Visual Studio 10 2010
-- Check for working C compiler using: Visual Studio 10 2010 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler using: Visual Studio 10 2010
-- Check for working CXX compiler using: Visual Studio 10 2010 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMAKE_SYSTEM_NAMEAndroid
-- Configuring done
-- Generating done
-- Build files have been written to:
H:/Pem_Code/hobby/grfxdemossdl2015/pemDemos/build-android-vs2010

However, vs2013 does not:

> cmake -G"Visual Studio 12 2013" -DCMAKE_SYSTEM_NAME="Android"  ..\pemDemos
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:1 (project):
  No CMAKE_C_COMPILER could be found.
CMake Error at CMakeLists.txt:1 (project):
  No CMAKE_CXX_COMPILER could be found.

This is with the stable release of cmake 3.1.1

I also tried a nightly build ( http://www.cmake.org/files/dev/?C=M;O=D ) ->
cmake-3.3.20150826-g566f1-win32-x86, and it gives the same error.

best regards,
Peter




On Thu, Aug 27, 2015 at 12:52 PM, Dmitry Polyanitsa 
wrote:

> I’m glad you like it J BTW generating for VS2013 + Nsight Tegra should
> already be supported in CMake. Support for VS2015 will be added to Nsight
> Tegra in the next release.
>
>
>
> -Dmitry
>
>
>
> *From:* Peter List [mailto:pem.l...@gmail.com]
> *Sent:* Thursday, August 27, 2015 1:36 AM
> *To:* Dmitry Polyanitsa 
> *Cc:* cmake-developers@cmake.org
> *Subject:* Re: [cmake-developers] nvidia nsight tegra set vcxproj
> properties (Ant Build) in cmake file
>
>
>
> Awesome - in that case I'll use this built-in support instead of spending
> time on writing a python script to call from add_custom_command().
>
>
>
> It's not officially documented yet ( http://bit.ly/1MOzB0S ), but I can
> use the link you sent ( http://bit.ly/1UdL3nc ) for documentation.
>
>
>
> I'm not sure whether this is in the CMake 3.3.1 release, but if not then I
> can try a nightly build:
>
>
>
> http://www.cmake.org/download/ -> http://www.cmake.org/files/dev/?C=M;O=D
> -> cmake-3.3.20150824-ga3d05-win32-x86.exe
>
>
>
> Or if that doesn't work, then maybe I'll wait a few days and try a newer
> nightly build :-)
>
>
>
> thank you,
>
> Peter
>
>
>
> PS: I love this built-in (nvidia tegra nsight + visual studio 2010)
> support...  Some similar things that would also be awesome as built-in
> support are...  nvidia tegra nsight + visual studio 2013, 2015.  nmake +
> Android Studio (Windows, Mac, Linux).  iOS + XCode.
>
>
>
>
>
>
>
>
>
> On Wed, Aug 26, 2015 at 7:15 AM, Dmitry Polyanitsa 
> wrote:
>
> Hi Peter,
>
>
>
> Note the commit Brad mentioned in another thread:
>
> > VS: Add more Nsight Tegra generator Android property settings
>
> > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c0afaf4
>
>
>
> It adds the ability to set both Native Library Directories and Native
> Library Dependencies, among other things. Thanks for the link to the forum
> post, by the way – we forgot to update it and will do that now.
>
>
>
> -Dmitry
>
>
>
> *From:* cmake-developers [mailto:cmake-developers-boun...@cmake.org] *On
> Behalf Of *Peter List
> *Sent:* Wednesday, August 26, 2015 5:06 AM
> *To:* cmake-developers@cmake.org
> *Subject:* [cmake-developers] nvidia nsight tegra set vcxproj properties
> (Ant Build) in cmake file
>
>
>
> I have a working hello world cmake + built-in Android using nvidia nsight
> tegra.  It uses SDL2.
>
>
>
> Unfortunately, after I run cmake I have to manually edit the following in
> my vcxproj to add SDL2:
>
>
>
> Configuration Properties > Ant Build > Native Library Directories, Native
> Library Dependencies
>
>
>
> I found this post ( http://bit.ly/1NTgTE3 ) from May 5th (3 months 20
> days ago) describing the same issue.  Is there an ETA on this?
>
>
>
> Since this isn't out yet, is there a work-around I can do instead?  So far
> my best idea is to have cmake use add_custom_command() as a post-build step
> to call a python script that edits the vcxproj file XML.
>
>
>
> 
>
>   [path]\build-android\android-project
>
>
> [path]\build-android\android-project\AndroidManifest.xml
>
>
> ../../../SDL2-2.0.3/libs/armeabi-v7a
>
>   SDL2
>
> 
>
>
>
> thank you
>
>
> --
>
> This email message is for the sole use of the intended recipient(s) and
> may contain confidential information.  Any unauthorized review, use,
> disclosure or distribution is prohibited.  If you are not the intended
> recipient, please contact the sender by reply email and des

[cmake-developers] [CMake 0015715]: COMMAND item of "add_custom_command" produce incorrect build.make

2015-08-27 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=15715 
== 
Reported By:shuaiw
Assigned To:
== 
Project:CMake
Issue ID:   15715
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   high
Status: new
== 
Date Submitted: 2015-08-27 21:26 EDT
Last Modified:  2015-08-27 21:26 EDT
== 
Summary:COMMAND item of "add_custom_command" produce
incorrect build.make
Description: 
add_custom_command(OUTPUT xele_mdapi.signature
COMMAND echo Xele-MD API Revision:${LASTREV} | tee xele_mdapi.signature
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
VERBATIM
COMMENT "Produce signature"
)

Steps to Reproduce: 
build in clion 1.1 OR 
enter ${CMAKE_HOME_DIRECTORY}/_build
cmake ..

Additional Information: 
partof generated build.make:
XeleMdAPI64/xele_mdapi.signature:
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --blue --bold
--progress-dir=/home/shuaiw/sw/trunk/xele_md/modules/xeleAPI-NMR-CMake/_build/CMakeFiles
--progress-num=$(CMAKE_PROGRESS_3) "Produce signature"
cd /home/shuaiw/sw/trunk/xele_md/modules/xeleAPI-NMR-CMake/XeleMdAPI64 &&
echo Xele-MD API Revision:820
 | tee xele_mdapi.signature ## this is newline

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-08-27 21:26 shuaiw 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] CTest XML outputs unsafe content

2015-08-27 Thread Daniel Pfeifer
On Thu, Aug 27, 2015 at 3:34 PM, Brad King  wrote:
> On 08/27/2015 07:20 AM, Mathieu MARACHE wrote:
>> I'm maintaining a CTest output parser for Bamboo. It was reported to me that
>> CMake 3.3.1 produced parsing issues in my plugin. After digging into CMake
>> source code, it seems that a bug was introduced with the replacement of
>> direct use of cmXMLSafe and std::ostream in favor of cmXMLwriter.
>
> For reference, the changes were here:
>
>  Merge topic 'ctest-xml-refactor'
>  http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=0c24c231
>
>> cmXMLWriter is, I assume wrongly, output Safe content without
>> (quotes, etc.) escaping.
>
> The SafeContent method is for text inside an element like
>
>  ContentHere
>
> The SafeAttribute method is for text inside an element attribute
>
>  
>
> The latter needs quotes to be encoded as """ but the former
> does not:
>
>  http://www.w3.org/TR/xml11/#syntax
>
> Have you found an attribute value that does not enocde quotes?

The proposed patch enables the encoding of quotes in content. This
does not seem correct to me.

I saw cmXMLSafe is used in some places inside CTest.
Since escaping is handled by cmXMLWriter, this may lead to some double
encodings.

I have attached two patches that remove all uses of cmXMLSafe from CTest.

-- Daniel
From 6a5962c671373f0c4e90080abc7b7fe7cf731f77 Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer 
Date: Thu, 16 Jul 2015 21:47:29 +0200
Subject: [PATCH 01/10] remove unused cmXMLSafe includes

---
 Source/CTest/cmCTestBZR.cxx| 1 -
 Source/CTest/cmCTestGIT.cxx| 1 -
 Source/CTest/cmCTestP4.cxx | 1 -
 Source/cmExtraKateGenerator.cxx| 1 -
 Source/cmExtraSublimeTextGenerator.cxx | 1 -
 5 files changed, 5 deletions(-)

diff --git a/Source/CTest/cmCTestBZR.cxx b/Source/CTest/cmCTestBZR.cxx
index 3014a93..587b583 100644
--- a/Source/CTest/cmCTestBZR.cxx
+++ b/Source/CTest/cmCTestBZR.cxx
@@ -14,7 +14,6 @@
 #include "cmCTest.h"
 #include "cmSystemTools.h"
 #include "cmXMLParser.h"
-#include "cmXMLSafe.h"
 
 #include 
 
diff --git a/Source/CTest/cmCTestGIT.cxx b/Source/CTest/cmCTestGIT.cxx
index 5b9208a..bbb3b9d 100644
--- a/Source/CTest/cmCTestGIT.cxx
+++ b/Source/CTest/cmCTestGIT.cxx
@@ -14,7 +14,6 @@
 #include "cmCTest.h"
 #include "cmSystemTools.h"
 #include "cmAlgorithms.h"
-#include "cmXMLSafe.h"
 
 #include 
 #include 
diff --git a/Source/CTest/cmCTestP4.cxx b/Source/CTest/cmCTestP4.cxx
index 5ce431a..5e0c54a 100644
--- a/Source/CTest/cmCTestP4.cxx
+++ b/Source/CTest/cmCTestP4.cxx
@@ -13,7 +13,6 @@
 
 #include "cmCTest.h"
 #include "cmSystemTools.h"
-#include "cmXMLSafe.h"
 
 #include 
 #include 
diff --git a/Source/cmExtraKateGenerator.cxx b/Source/cmExtraKateGenerator.cxx
index 578e7d3..f83b5cf 100644
--- a/Source/cmExtraKateGenerator.cxx
+++ b/Source/cmExtraKateGenerator.cxx
@@ -19,7 +19,6 @@
 #include "cmGeneratedFileStream.h"
 #include "cmTarget.h"
 #include "cmSystemTools.h"
-#include "cmXMLSafe.h"
 
 #include 
 
diff --git a/Source/cmExtraSublimeTextGenerator.cxx b/Source/cmExtraSublimeTextGenerator.cxx
index 4e721d4..163a75b 100644
--- a/Source/cmExtraSublimeTextGenerator.cxx
+++ b/Source/cmExtraSublimeTextGenerator.cxx
@@ -21,7 +21,6 @@
 #include "cmSourceFile.h"
 #include "cmSystemTools.h"
 #include "cmTarget.h"
-#include "cmXMLSafe.h"
 
 #include 
 
-- 
2.5.0

From 0e640887f75bb354674129bb743753fb2b6e64fc Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer 
Date: Thu, 16 Jul 2015 21:48:00 +0200
Subject: [PATCH 02/10] remove all usage of cmXMLSafe from CTest escaping is
 handled by cmXMLWriter

---
 Source/CTest/cmCTestMemCheckHandler.cxx | 16 ++--
 Source/CTest/cmCTestTestHandler.cxx |  2 +-
 Source/cmCTest.cxx  |  5 +
 3 files changed, 8 insertions(+), 15 deletions(-)

diff --git a/Source/CTest/cmCTestMemCheckHandler.cxx b/Source/CTest/cmCTestMemCheckHandler.cxx
index 8f26716..acf527a 100644
--- a/Source/CTest/cmCTestMemCheckHandler.cxx
+++ b/Source/CTest/cmCTestMemCheckHandler.cxx
@@ -80,8 +80,8 @@ public:
   int i = 0;
   for(; atts[i] != 0; i+=2)
 {
-ostr << "   " << cmXMLSafe(atts[i])
- << " - " << cmXMLSafe(atts[i+1]) << "\n";
+ostr << "   " << atts[i]
+ << " - " << atts[i+1] << "\n";
 }
   ostr << "\n";
   this->Log += ostr.str();
@@ -856,7 +856,7 @@ bool cmCTestMemCheckHandler::ProcessMemCheckSanitizerOutput(
   defects++;
   ostr << "" <<  this->ResultStrings[idx] << " ";
   }
-ostr << cmXMLSafe(*i) << std::endl;
+ostr << *i << std::endl;
 }
   log = ostr.str();
   if(defects)
@@ -908,7 +908,7 @@ bool cmCTestMemCheckHandler::ProcessMemCheckPurifyOutput(
   results[failure] ++;
   defects ++;
   }
-ostr << cmXMLSafe(*i) << std::endl;
+ostr << *i << std::endl;
 }
 
   log = ostr.str();
@@ -1056,7 +1056,7 @@ bool cmCTestMemCheckHandler::ProcessMemCheckValgrindOutput(
 defects ++;
 }
   totalOutputSize += lines[cc]

Re: [cmake-developers] nvidia nsight tegra set vcxproj properties (Ant Build) in cmake file

2015-08-27 Thread Dmitry Polyanitsa
I’m glad you like it ☺ BTW generating for VS2013 + Nsight Tegra should already 
be supported in CMake. Support for VS2015 will be added to Nsight Tegra in the 
next release.

-Dmitry

From: Peter List [mailto:pem.l...@gmail.com]
Sent: Thursday, August 27, 2015 1:36 AM
To: Dmitry Polyanitsa 
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] nvidia nsight tegra set vcxproj properties (Ant 
Build) in cmake file

Awesome - in that case I'll use this built-in support instead of spending time 
on writing a python script to call from add_custom_command().

It's not officially documented yet ( http://bit.ly/1MOzB0S ), but I can use the 
link you sent ( http://bit.ly/1UdL3nc ) for documentation.

I'm not sure whether this is in the CMake 3.3.1 release, but if not then I can 
try a nightly build:

http://www.cmake.org/download/ -> http://www.cmake.org/files/dev/?C=M;O=D -> 
cmake-3.3.20150824-ga3d05-win32-x86.exe

Or if that doesn't work, then maybe I'll wait a few days and try a newer 
nightly build :-)

thank you,
Peter

PS: I love this built-in (nvidia tegra nsight + visual studio 2010) support...  
Some similar things that would also be awesome as built-in support are...  
nvidia tegra nsight + visual studio 2013, 2015.  nmake + Android Studio 
(Windows, Mac, Linux).  iOS + XCode.




On Wed, Aug 26, 2015 at 7:15 AM, Dmitry Polyanitsa 
mailto:dpolyani...@nvidia.com>> wrote:
Hi Peter,

Note the commit Brad mentioned in another thread:

> VS: Add more Nsight Tegra generator Android property settings

> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c0afaf4

It adds the ability to set both Native Library Directories and Native Library 
Dependencies, among other things. Thanks for the link to the forum post, by the 
way – we forgot to update it and will do that now.

-Dmitry

From: cmake-developers 
[mailto:cmake-developers-boun...@cmake.org]
 On Behalf Of Peter List
Sent: Wednesday, August 26, 2015 5:06 AM
To: cmake-developers@cmake.org
Subject: [cmake-developers] nvidia nsight tegra set vcxproj properties (Ant 
Build) in cmake file

I have a working hello world cmake + built-in Android using nvidia nsight 
tegra.  It uses SDL2.

Unfortunately, after I run cmake I have to manually edit the following in my 
vcxproj to add SDL2:

Configuration Properties > Ant Build > Native Library Directories, Native 
Library Dependencies

I found this post ( http://bit.ly/1NTgTE3 ) from May 5th (3 months 20 days ago) 
describing the same issue.  Is there an ETA on this?

Since this isn't out yet, is there a work-around I can do instead?  So far my 
best idea is to have cmake use add_custom_command() as a post-build step to 
call a python script that edits the vcxproj file XML.


  [path]\build-android\android-project
  
[path]\build-android\android-project\AndroidManifest.xml
  
../../../SDL2-2.0.3/libs/armeabi-v7a
  SDL2


thank you


This email message is for the sole use of the intended recipient(s) and may 
contain confidential information.  Any unauthorized review, use, disclosure or 
distribution is prohibited.  If you are not the intended recipient, please 
contact the sender by reply email and destroy all copies of the original 
message.


-- 

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] Is there an official FindMKL module?

2015-08-27 Thread Tim Gallagher
Hi Siebren, 

I tried to link statically and it did not work for me, similar errors as to 
what you are getting. 

The way the macro is supposed to work -- it checks for the MKL link tool and if 
it is available, it uses and provides the libraries needed. If it is 
unavailable (or throws errors or whatever else the case may be), then FindBLAS 
reverts back to the way it handles MKL currently. 

I have attached the module that provides the interface to the MKL command line 
tool as well as the changed FindBLAS module that uses it. Major caveat here -- 
I have not used these since 2012, with one of the Intel 12.something compilers 
and CMake 2.8. I did a quick diff on the FindBLAS in the current version and 
the CMake 2.8 version and there's only very minor changes that shouldn't affect 
this working. If it turns out this is useful and close to functional, then we 
can work on getting it current. 

Tim 

- Original Message -

From: "Siebren Reker"  
To: "tim gallagher"  
Cc: cmake-developers@cmake.org 
Sent: Thursday, August 27, 2015 11:16:34 AM 
Subject: Re: [cmake-developers] Is there an official FindMKL module? 


Hi Tim, 



On Thu, Aug 27, 2015 at 4:32 PM, Tim Gallagher < tim.gallag...@gatech.edu > 
wrote: 




Siebren, 

We've never really used static linking so I am not sure if it ever really 
worked. I can try and let you know. 




Could you please do so? Just to verify that I'm not doing something obviously 
wrong 




However, I'm having flashbacks here to something I thought I had done before. I 
dug through my emails and back in 2012 I had signed up to maintain a new module 
that provided a macro to interface with the MKL tool and generated the proper 
linking based on what it reported. My colleague and I had written it because we 
were tired of the difficulties in the current modules. This new module provided 
a macro and the FindBLAS and FindLAPACK modules would call the macro to get the 
link information. 





Sounds clean, but are you sure the tool is always available? 




I got push access to create the topic branch but then I don't know what 
happened. I don't know if I never pushed it, or it never got 
tested/approved/checked, no clue. I actually still have all of the modules and 
changes I had made, but it was in version 2.8. I wish I could remember if I had 
actually pushed it to CMake or not, but I really don't remember why it never 
happened. 

So anyway, now that we're discussing it again, if the CMake community wants the 
MKL support improved, I can dust off the modules and see what it would take to 
get it officially in the stream. 




I'd be more than happy to test this. I've found a number of hits on Google for 
FindMKL.cmake files. I certainly wasn't alone in having trouble to get this to 
work (doesn't mean much of course). 


best, 
Siebren 




Tim 



From: "Siebren Reker" < siebren.re...@gmail.com > 
To: "tim gallagher" < tim.gallag...@gatech.edu > 
Cc: cmake-developers@cmake.org 
Sent: Thursday, August 27, 2015 6:32:17 AM 
Subject: Re: [cmake-developers] Is there an official FindMKL module? 




Hi Tim, 


Quick add-on to my previous email. With BLA_STATIC ON, I see from the 
CMakeError.log that the static libraries ARE found (I was trusting the), but 
the linking of the test program goes wrong: 
undefined reference to `mkl_blas_sgemv` 
But that function IS implemented in one of the three libraries that is found, 
in my case in libmkl_sequential.a 


So this is probably a linking/ library ordering error. 
Indeed, Intel fora and the link advisor I mentioned earlier also report the 
need for grouping these as in 
-Wl,--start-group ${MKLROOT}/lib/intel64/libmkl_intel_lp64.a 
${MKLROOT}/lib/intel64/libmkl_core.a ${MKLROOT}/lib/intel64/libmkl_sequential.a 
-Wl,--end-group 



Is my understanding correct, and can this be fixed? 


kind regards, 
Siebren 




On Thu, Aug 27, 2015 at 11:50 AM, Siebren Reker < siebren.re...@gmail.com > 
wrote: 



Hi Tim, 


That is encouraging, thanks. I went back and tried harder this time, when I 
specified BLA_VENDOR precisely and leave BLA_STATIC off, I am able to get to 
the correct versions. 
In the very same directory where the shared libraries are found, I have the 
static libraries as well, but BLA_STATIC on in that case does not find the 
libraries. 


I've read up a bit on this now, so maybe the following information is helpful: 
This is a CMake 3.3.0 installation 
My project has both C and Fortran enabled 
I call it as follows: 


set( BLA_STATIC ON) 
set( BLA_VENDOR "Intel10_64lp_seq") 

find_package( BLAS ) 


Is BLA_STATIC = ON working for you? 


A separate question I have is if the linker command that will be produced 
afterwards is of course different from the one supplied by Intel in their tool. 
Should that not concern me? 


kind regards, 
Siebren 






On Wed, Aug 26, 2015 at 4:59 PM, Tim Gallagher < tim.gallag...@gatech.edu > 
wrote: 




We sometime struggled to get it working, but we never had to resort to usin

[cmake-developers] [CMake 0015714]: Support for mips64, mips64el, mipsn32, mipsn32el in FindJNI

2015-08-27 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=15714 
== 
Reported By:Felix Geyer
Assigned To:
== 
Project:CMake
Issue ID:   15714
Category:   Modules
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-08-27 13:14 EDT
Last Modified:  2015-08-27 13:14 EDT
== 
Summary:Support for mips64, mips64el, mipsn32, mipsn32el in
FindJNI
Description: 
In the Debian package we are carrying the attached patch to add support
for mips64, mips64el, mipsn32 and mipsn32el in FindJNI.cmake.

It would be great to have this applied upstream.

Original bug report:
https://bugs.debian.org/747174
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-08-27 13:14 Felix GeyerNew Issue
2015-08-27 13:14 Felix GeyerFile Added: FindJNI.cmake.mips.patch
   
==

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] [PATCH] Add support for Xcode ORGANIZATIONNAME project setting via CMAKE_XCODE_ORGANIZATIONNAME.

2015-08-27 Thread Cody Krieger
On Aug 27, 2015, at 6:39 AM, Brad King  wrote:On 08/25/2015 01:00 PM, Cody Krieger wrote://  Created by Joe Schmoe on 8/25/15.//  Copyright (c) 2015 My Company, Inc. All rights reserved.CMake-generated Xcode project files are not meant for redistribution.What other effects does such a notice have?  Does it appear in theIDE somewhere?The organization name setting for a given Xcode project is primarily (only?) used to fill out copyright notices in file templates for various languages. It doesn't have any other effects to my knowledge. The only official documentation I can find seems to agree with me (https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/ConfiguringYourApp/ConfiguringYourApp.html):“The organization name is an attribute of the Xcode project and is used in boilerplate text throughout your project folder. For example, the organization name is used in the source and header file copyright strings.”To understand the motivation behind this change: my team's workflow generally involves creating new source files from within Xcode (and then adding those files to a target in the relevant CMakeLists.txt file) since it handily populates the new files with the aforementioned header comments—and with this change, we no longer have to manually add the copyright string. (We certainly don't intend to redistribute the CMake-generated Xcode project files.)I tried to adhere to the surrounding coding style and whatnot.Let me know if anything needs massaging.The change itself looks good.  Please also add a Help/variable/CMAKE_XCODE_ORGANIZATIONNAME.rstfile with documentation.  Also reference it from Help/manual/cmake-variables.7.rstThanks,-BradUpdated patch attached.Thanks!Cody

v2-0001-Add-support-for-Xcode-ORGANIZATIONNAME-project-se.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

Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens

2015-08-27 Thread Brad King
On 08/27/2015 10:06 AM, James Johnston wrote:
> I would vote naming it TO_NATIVE_PATH instead of PATH_FOR_SHELL, for
> consistency with the existing parameter in the file command.

The file(TO_NATIVE_PATH) command is hopelessly ill-defined:

 http://www.cmake.org/Bug/view.php?id=5939

See also existing discussion about a genex for such conversions:

 http://www.cmake.org/Bug/view.php?id=15509

-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] Is there an official FindMKL module?

2015-08-27 Thread Siebren Reker
Hi Tim,

On Thu, Aug 27, 2015 at 4:32 PM, Tim Gallagher 
wrote:

> Siebren,
>
> We've never really used static linking so I am not sure if it ever really
> worked. I can try and let you know.
>

Could you please do so? Just to verify that I'm not doing something
obviously wrong


> However, I'm having flashbacks here to something I thought I had done
> before. I dug through my emails and back in 2012 I had signed up to
> maintain a new module that provided a macro to interface with the MKL tool
> and generated the proper linking based on what it reported. My colleague
> and I had written it because we were tired of the difficulties in the
> current modules. This new module provided a macro and the FindBLAS and
> FindLAPACK modules would call the macro to get the link information.
>

Sounds clean, but are you sure the tool is always available?


> I got push access to create the topic branch but then I don't know what
> happened. I don't know if I never pushed it, or it never got
> tested/approved/checked, no clue. I actually still have all of the modules
> and changes I had made, but it was in version 2.8. I wish I could remember
> if I had actually pushed it to CMake or not, but I really don't remember
> why it never happened.
>
> So anyway, now that we're discussing it again, if the CMake community
> wants the MKL support improved, I can dust off the modules and see what it
> would take to get it officially in the stream.
>

I'd be more than happy to test this. I've found a number of hits on Google
for FindMKL.cmake files. I certainly wasn't alone in having trouble to get
this to work (doesn't mean much of course).

best,
Siebren


> Tim
>
> --
> *From: *"Siebren Reker" 
> *To: *"tim gallagher" 
> *Cc: *cmake-developers@cmake.org
> *Sent: *Thursday, August 27, 2015 6:32:17 AM
> *Subject: *Re: [cmake-developers] Is there an official FindMKL module?
>
>
> Hi Tim,
>
> Quick add-on to my previous email. With BLA_STATIC ON, I see from the
> CMakeError.log that the static libraries ARE found (I was trusting the),
> but the linking of the test program goes wrong:
> undefined reference to `mkl_blas_sgemv`
> But that function IS implemented in one of the three libraries that is
> found, in my case in libmkl_sequential.a
>
> So this is probably a linking/ library ordering error.
> Indeed, Intel fora and the link advisor I mentioned earlier also report
> the need for grouping these as in
>  -Wl,--start-group ${MKLROOT}/lib/intel64/libmkl_intel_lp64.a
> ${MKLROOT}/lib/intel64/libmkl_core.a
> ${MKLROOT}/lib/intel64/libmkl_sequential.a -Wl,--end-group
>
> Is my understanding correct, and can this be fixed?
>
> kind regards,
> Siebren
>
>
> On Thu, Aug 27, 2015 at 11:50 AM, Siebren Reker 
> wrote:
>
>> Hi Tim,
>>
>> That is encouraging, thanks. I went back and tried harder this time, when
>> I specified BLA_VENDOR precisely and leave BLA_STATIC off, I am able to get
>> to the correct versions.
>> In the very same directory where the shared libraries are found, I have
>> the static libraries as well, but BLA_STATIC on in that case does not find
>> the libraries.
>>
>> I've read up a bit on this now, so maybe the following information is
>> helpful:
>> This is a CMake 3.3.0 installation
>> My project has both C and Fortran enabled
>> I call it as follows:
>>
>> set( BLA_STATIC ON)
>> set( BLA_VENDOR "Intel10_64lp_seq")
>> find_package( BLAS )
>>
>> Is BLA_STATIC = ON working for you?
>>
>> A separate question I have is if the linker command that will be produced
>> afterwards is of course different from the one supplied by Intel in their
>> tool. Should that not concern me?
>>
>> kind regards,
>> Siebren
>>
>>
>> On Wed, Aug 26, 2015 at 4:59 PM, Tim Gallagher 
>> wrote:
>>
>>> We sometime struggled to get it working, but we never had to resort to
>>> using a FindMKL -- FindBLAS and FindLAPACK work just fine for us, provided
>>> we do things "correctly."
>>>
>>> So long as we have sourced the mklvars script that ships with Intel MKL
>>> and we put:
>>>
>>> BLA_VENDOR=Intel10_64lp_seq ccmake /path/to/source/dir
>>>
>>>
>>> Then everything works fine and we have no issues. So we have to give
>>> CMake a hint that we want to pick the Intel version rather than the generic
>>> one (and we're using the sequential, 64bit MKL -- if you look in FindBLAS
>>> you can see other vendor types).
>>>
>>> Have you had things fail when you setup your environment variables using
>>> the scripts Intel provides and when you set the BLA_VENDOR hint as an
>>> environment variable?
>>>
>>> Tim
>>>
>>> --
>>> *From: *"Siebren Reker" 
>>> *To: *cmake-developers@cmake.org
>>> *Sent: *Wednesday, August 26, 2015 10:18:44 AM
>>> *Subject: *[cmake-developers] Is there an official FindMKL module?
>>>
>>>
>>> Hello,
>>>
>>> I am using the find_package() command to load settings for the Intel
>>> Math Kernel Library (MKL). This works through a custom FindMKL.cmake module
>>> that I've made for myself

Re: [cmake-developers] [PATCH] Use dllexport and dllimport on Cygwin too

2015-08-27 Thread Brad King
On 08/27/2015 03:48 AM, Tony Kelman wrote:
> First hunk below is from Yaakov Selkowitz, it was reported to be 
> necessary to build KF5 in Cygwin. Second hunk fixes the corresponding 
> test to account for the change. Currently the MinGW platform reference 
> outputs appear to match the Cygwin results here, though a separate new 
> pair of reference outputs just for Cygwin could of course work for this 
> too.

Applied, thanks:

 GenerateExportHeader: Use dllexport/dllimport on Cygwin
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3e2865b4

-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] Fixing bug #12506 (iOS install)

2015-08-27 Thread Ruslan Baratov via cmake-developers

On 26-Aug-15 22:53, Gregor Jasny wrote:

Hallo,

On 13/08/15 12:56, Ruslan Baratov wrote:

On 13-Aug-15 08:46, Gregor Jasny wrote:

On 13/08/15 01:44, Ruslan Baratov via cmake-developers wrote:

Sending patches with fix. Now it's possible to install simulator
libraries by:

  > cmake --build _builds --config Release --target install -- -sdk
iphonesimulator

and device libraries by:

  > cmake --build _builds --config Release --target install -- -sdk
iphoneos

or from Xcode IDE (build target install).

However this commands will install both libraries to the same location.
This behaviour can be improved by adding some code that will do lipo of
all libraries before install (i.e. universal libraries will be
installed). This can be achieved by using ONLY_ACTIVE_ARCHS=NO while
running Xcode build. The only question is about making install target
depends on two type of builds (-sdk iphonesimulator and -sdk iphoneos).

This was my preliminary work:

https://github.com/gjasny/CMake/commit/978dca25ac387bdec894a1ba2c934317f5f6169f


This looks great! I've spent several hours trying to figure out how
'$(EFFECTIVE_PLATFORM_NAME)' can be set to Xcode and some CMake friendly
string to cmake_install.cmake script. I didn't know Xcode understand
`${VAR}` syntax (probably it didn't, it's just expanded as an
environment variable). I've tested your fix and it works fine for me.
Since we don't need to replace string with path manually I think your
solution is neater. I've added description to commit and rebased it, see
attachment.

I just pushed the fix-ios-install topic including a test. Basically the
patch changes the invocation line of the script from

cmake -DBUILD_TYPE=Release-iphoneos -P cmake_install.cmake

to

cmake -DBUILD_TYPE=Release -DEFFECTIVE_PLATFORM_NAME=-iphoneos -P
cmake_install.cmake

and within the install script

file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/lib" TYPE
STATIC_LIBRARY FILES ".../Release/libfoo.a")


to

file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/lib" TYPE
STATIC_LIBRARY FILES ".../Release${EFFECTIVE_PLATFORM_NAME}/libfoo.a")


By keeping the ${EFFECTIVE_PLATFORM_NAME} a variable one is able to use
the same install script for iphoneos and iphonesimulator SDKs.

Please review and merge.

Thanks,
Gregor

Works fine for me with rebased version. Though some tests failed:

The following tests FAILED:
   14 - kwsys.testDynamicLoader (Failed)
  372 - RunCMake.FindPkgConfig (Failed)
  392 - FindPackageModeMakefileTest (Failed)

I've tried version without patches (81ad562) and see this failures too, 
so I guess it's not because of iOS fixes.


From my experience changes expected to be in format of `git 
format-patch` command, so attaching them.


Thanks, Ruslo
>From daa92aa633809c196380ef544b8a193cfcd15d27 Mon Sep 17 00:00:00 2001
From: Gregor Jasny 
Date: Thu, 20 Aug 2015 22:29:49 +0200
Subject: [PATCH 1/3] Replace CMAKE_XCODE_EFFECTIVE_PLATFORMS with call to
 PlatformIsAppleIos

Currently the CMAKE_XCODE_EFFECTIVE_PLATFORMS property acts only as
a kind of toggle switch to enable iOS project layout features.
But instead of relying on this undocumented property, better detect
the presence of an iOS SDK directly.
---
 Source/cmTarget.cxx| 5 ++---
 Tests/RunCMake/XcodeProject/XcodeBundles.cmake | 1 -
 Tests/iOSNavApp/CMakeLists.txt | 1 -
 3 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 49b3239..da314a6 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -3566,10 +3566,9 @@ bool cmTarget::ComputeOutputDir(const std::string& config,
   // The generator may add the configuration's subdirectory.
   if(!conf.empty())
 {
-const char *platforms = this->Makefile->GetDefinition(
-  "CMAKE_XCODE_EFFECTIVE_PLATFORMS");
+bool iosPlatform = this->Makefile->PlatformIsAppleIos();
 std::string suffix =
-  usesDefaultOutputDir && platforms ? "$(EFFECTIVE_PLATFORM_NAME)" : "";
+  usesDefaultOutputDir && iosPlatform ? "$(EFFECTIVE_PLATFORM_NAME)" : "";
 this->Makefile->GetGlobalGenerator()->
   AppendDirectoryForConfig("/", conf, suffix, out);
 }
diff --git a/Tests/RunCMake/XcodeProject/XcodeBundles.cmake b/Tests/RunCMake/XcodeProject/XcodeBundles.cmake
index d5cb51f..2cbccfa 100644
--- a/Tests/RunCMake/XcodeProject/XcodeBundles.cmake
+++ b/Tests/RunCMake/XcodeProject/XcodeBundles.cmake
@@ -6,7 +6,6 @@ enable_language(C)
 if(TEST_IOS)
   set(CMAKE_OSX_SYSROOT iphoneos)
   set(CMAKE_OSX_ARCHITECTURES "armv7")
-  set(CMAKE_XCODE_EFFECTIVE_PLATFORMS "-iphoneos;-iphonesimulator")
   set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED "NO")
   set(CMAKE_XCODE_ATTRIBUTE_ENABLE_BITCODE "NO")
 endif(TEST_IOS)
diff --git a/Tests/iOSNavApp/CMakeLists.txt b/Tests/iOSNavApp/CMakeLists.txt
index 12c3ada..1fc33e0 100644
--- a/Tests/iOSNavApp/CMakeLists.txt
+++ b/Tests/iOSNavApp/CMakeLists.txt
@@ -3,7 +3,6 @@ project(NavApp3)
 
 set(CMAKE_OSX_SYSROOT iphoneos4.3)
 set(CMAKE_

Re: [cmake-developers] Is there an official FindMKL module?

2015-08-27 Thread Tim Gallagher
Siebren, 

We've never really used static linking so I am not sure if it ever really 
worked. I can try and let you know. 

However, I'm having flashbacks here to something I thought I had done before. I 
dug through my emails and back in 2012 I had signed up to maintain a new module 
that provided a macro to interface with the MKL tool and generated the proper 
linking based on what it reported. My colleague and I had written it because we 
were tired of the difficulties in the current modules. This new module provided 
a macro and the FindBLAS and FindLAPACK modules would call the macro to get the 
link information. 

I got push access to create the topic branch but then I don't know what 
happened. I don't know if I never pushed it, or it never got 
tested/approved/checked, no clue. I actually still have all of the modules and 
changes I had made, but it was in version 2.8. I wish I could remember if I had 
actually pushed it to CMake or not, but I really don't remember why it never 
happened. 

So anyway, now that we're discussing it again, if the CMake community wants the 
MKL support improved, I can dust off the modules and see what it would take to 
get it officially in the stream. 

Tim 

- Original Message -

From: "Siebren Reker"  
To: "tim gallagher"  
Cc: cmake-developers@cmake.org 
Sent: Thursday, August 27, 2015 6:32:17 AM 
Subject: Re: [cmake-developers] Is there an official FindMKL module? 


Hi Tim, 


Quick add-on to my previous email. With BLA_STATIC ON, I see from the 
CMakeError.log that the static libraries ARE found (I was trusting the), but 
the linking of the test program goes wrong: 
undefined reference to `mkl_blas_sgemv` 
But that function IS implemented in one of the three libraries that is found, 
in my case in libmkl_sequential.a 


So this is probably a linking/ library ordering error. 
Indeed, Intel fora and the link advisor I mentioned earlier also report the 
need for grouping these as in 
-Wl,--start-group ${MKLROOT}/lib/intel64/libmkl_intel_lp64.a 
${MKLROOT}/lib/intel64/libmkl_core.a ${MKLROOT}/lib/intel64/libmkl_sequential.a 
-Wl,--end-group 



Is my understanding correct, and can this be fixed? 


kind regards, 
Siebren 




On Thu, Aug 27, 2015 at 11:50 AM, Siebren Reker < siebren.re...@gmail.com > 
wrote: 



Hi Tim, 


That is encouraging, thanks. I went back and tried harder this time, when I 
specified BLA_VENDOR precisely and leave BLA_STATIC off, I am able to get to 
the correct versions. 
In the very same directory where the shared libraries are found, I have the 
static libraries as well, but BLA_STATIC on in that case does not find the 
libraries. 


I've read up a bit on this now, so maybe the following information is helpful: 
This is a CMake 3.3.0 installation 
My project has both C and Fortran enabled 
I call it as follows: 


set( BLA_STATIC ON) 
set( BLA_VENDOR "Intel10_64lp_seq") 

find_package( BLAS ) 


Is BLA_STATIC = ON working for you? 


A separate question I have is if the linker command that will be produced 
afterwards is of course different from the one supplied by Intel in their tool. 
Should that not concern me? 


kind regards, 
Siebren 






On Wed, Aug 26, 2015 at 4:59 PM, Tim Gallagher < tim.gallag...@gatech.edu > 
wrote: 




We sometime struggled to get it working, but we never had to resort to using a 
FindMKL -- FindBLAS and FindLAPACK work just fine for us, provided we do things 
"correctly." 

So long as we have sourced the mklvars script that ships with Intel MKL and we 
put: 

BLA_VENDOR =Intel10_64lp_seq ccmake /path/to/source/dir 
Then everything works fine and we have no issues. So we have to give CMake a 
hint that we want to pick the Intel version rather than the generic one (and 
we're using the sequential, 64bit MKL -- if you look in FindBLAS you can see 
other vendor types). 

Have you had things fail when you setup your environment variables using the 
scripts Intel provides and when you set the BLA_VENDOR hint as an environment 
variable? 

Tim 



From: "Siebren Reker" < siebren.re...@gmail.com > 
To: cmake-developers@cmake.org 
Sent: Wednesday, August 26, 2015 10:18:44 AM 
Subject: [cmake-developers] Is there an official FindMKL module? 




Hello, 


I am using the find_package() command to load settings for the Intel Math 
Kernel Library (MKL). This works through a custom FindMKL.cmake module that 
I've made for myself. 


However, when looking at: 
https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/ 

I can tell that what I've done is likely only correct for my specific case, and 
certainly not robust against library version changes and various other changes 
(openmp, static vs dynamic linking etc.). 



Instead of a FindMKL.cmake module, an alternative is to have MKL be discovered 
in the FindBLAS or FindLAPACK modules, but according to what I can find on the 
bug tracker, that solution is also in a fairly broken state: 

Bug 14138: http://www.cmake.org/Bug/view.php?id=14138 

Bug 1

Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens

2015-08-27 Thread Kislinskiy, Stefan
Yes, TO_CMAKE_PATH is used quite often. Just imagine parsing paths as input. Or 
when you create CMake scripts during the build you might want to call 
file(TO_CMAKE_PATH) in there. It makes sense on both ends, as input and output. 
:) I also vote for consistent naming, if the generator expressions are chosen 
as the final solution.

-Original Message-
From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of 
James Johnston
Sent: Donnerstag, 27. August 2015 16:06
To: cmake-developers@cmake.org
Subject: Re: [cmake-developers] ExternalProject: Use native paths as substitute 
for directory tokens

> -Original Message-
> From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
> On Behalf Of Kislinskiy, Stefan
> Sent: Thursday, August 27, 2015 13:44
> To: Brad King; CHEVRIER, Marc; David Cole
> Cc: cmake-developers@cmake.org
> Subject: Re: [cmake-developers] ExternalProject: Use native paths as 
> substitute for directory tokens
> 
> This is pretty nice from the perspective of an engineer. But I wonder 
> if
it
> wouldn't be kind of over-engineered in the sense that it would be a 
> rather hidden feature for the purpose? -- I probably wouldn't think of 
> searching
for
> a generator expression in the documentation when I have trouble with 
> the replacement of directory tokens. Then again, there could be a hint 
> in the ExternalProject documentation which would be fine I guess. One 
> way or another, I would be happy if we could determine what the patch 
> should provide exactly so that we come to an end. :-) Thank you for 
> all the
feedback
> so far.

I think Brad raises an excellent point here though I hadn't thought of...
implementing the underlying functionality as a generator expression allows the 
problem to be solved outside of the scope of ExternalProject when it arises...  
For example if I add_custom_command as a custom build step and need to pass a 
native path argument to it - a path known only at generate time.  I guess it is 
not possible right now?

> Another approach is to introduce a generator expression to transform 
> the path slash style.  Then it could be used both for ExternalProject 
> and in
other
> custom commands.  E.g.
> 
>  $/bootstrap${shell_ext}>
> 
> In this case  would be replaced with forward slashes by 
> ExternalProject but then at generate time CMake would evaluate the 
> genex to convert slashes as needed.

I would vote naming it TO_NATIVE_PATH instead of PATH_FOR_SHELL, for 
consistency with the existing parameter in the file command.  There could then 
also be a corresponding TO_CMAKE_PATH gen-exp, although I wonder if it would be 
used much.  (Then again, do people even use file(TO_CMAKE_PATH) very much?) 

James


-- 

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
-- 

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] ExternalProject: Use native paths as substitute for directory tokens

2015-08-27 Thread James Johnston
> -Original Message-
> From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
> On Behalf Of Kislinskiy, Stefan
> Sent: Thursday, August 27, 2015 13:44
> To: Brad King; CHEVRIER, Marc; David Cole
> Cc: cmake-developers@cmake.org
> Subject: Re: [cmake-developers] ExternalProject: Use native paths as
> substitute for directory tokens
> 
> This is pretty nice from the perspective of an engineer. But I wonder if
it
> wouldn't be kind of over-engineered in the sense that it would be a rather
> hidden feature for the purpose? -- I probably wouldn't think of searching
for
> a generator expression in the documentation when I have trouble with the
> replacement of directory tokens. Then again, there could be a hint in the
> ExternalProject documentation which would be fine I guess. One way or
> another, I would be happy if we could determine what the patch should
> provide exactly so that we come to an end. :-) Thank you for all the
feedback
> so far.

I think Brad raises an excellent point here though I hadn't thought of...
implementing the underlying functionality as a generator expression allows
the problem to be solved outside of the scope of ExternalProject when it
arises...  For example if I add_custom_command as a custom build step and
need to pass a native path argument to it - a path known only at generate
time.  I guess it is not possible right now?

> Another approach is to introduce a generator expression to transform the
> path slash style.  Then it could be used both for ExternalProject and in
other
> custom commands.  E.g.
> 
>  $/bootstrap${shell_ext}>
> 
> In this case  would be replaced with forward slashes by
> ExternalProject but then at generate time CMake would evaluate the genex
> to convert slashes as needed.

I would vote naming it TO_NATIVE_PATH instead of PATH_FOR_SHELL, for
consistency with the existing parameter in the file command.  There could
then also be a corresponding TO_CMAKE_PATH gen-exp, although I wonder if it
would be used much.  (Then again, do people even use file(TO_CMAKE_PATH)
very much?) 

James


-- 

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] Java support

2015-08-27 Thread Brad King
On 08/21/2015 09:50 AM, Brad King wrote:
>  UseJava: Add support for javah tool
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4476feac
> 
> There is still one failure on the dashboard but I think it is
> related to the way the run is configured rather than a problem
> with the source.  Once I've worked that out I'll report back.

That has been resolved.  I've merged the above change to 'master'.

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


Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens

2015-08-27 Thread Kislinskiy, Stefan
This is pretty nice from the perspective of an engineer. But I wonder if it 
wouldn't be kind of over-engineered in the sense that it would be a rather 
hidden feature for the purpose? -- I probably wouldn't think of searching for a 
generator expression in the documentation when I have trouble with the 
replacement of directory tokens. Then again, there could be a hint in the 
ExternalProject documentation which would be fine I guess. One way or another, 
I would be happy if we could determine what the patch should provide exactly so 
that we come to an end. :-) Thank you for all the feedback so far.  


-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Donnerstag, 27. August 2015 15:10
To: Kislinskiy, Stefan; CHEVRIER, Marc; David Cole
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] ExternalProject: Use native paths as substitute 
for directory tokens

On 08/26/2015 03:35 AM, Kislinskiy, Stefan wrote:
> Would you prefer to have a switch for each *_DIR variable for all 
> target steps, or a common switch but for each target step, like the 
> new USE_TERMINAL switches in the master?
[snip]
> Von: CHEVRIER, Marc [marc.chevr...@sap.com] Offering the possibility 
> to manage native paths in an easy way is a very good enhancement

Another approach is to introduce a generator expression to transform the path 
slash style.  Then it could be used both for ExternalProject and in other 
custom commands.  E.g.

 $/bootstrap${shell_ext}>

In this case  would be replaced with forward slashes by 
ExternalProject but then at generate time CMake would evaluate the genex to 
convert slashes as needed.

-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] CTest XML outputs unsafe content

2015-08-27 Thread Brad King
On 08/27/2015 07:20 AM, Mathieu MARACHE wrote:
> I'm maintaining a CTest output parser for Bamboo. It was reported to me that
> CMake 3.3.1 produced parsing issues in my plugin. After digging into CMake
> source code, it seems that a bug was introduced with the replacement of
> direct use of cmXMLSafe and std::ostream in favor of cmXMLwriter.

For reference, the changes were here:

 Merge topic 'ctest-xml-refactor'
 http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=0c24c231

> cmXMLWriter is, I assume wrongly, output Safe content without
> (quotes, etc.) escaping.

The SafeContent method is for text inside an element like

 ContentHere

The SafeAttribute method is for text inside an element attribute

 

The latter needs quotes to be encoded as """ but the former
does not:

 http://www.w3.org/TR/xml11/#syntax

Have you found an attribute value that does not enocde quotes?

-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] Add support for Xcode ORGANIZATIONNAME project setting via CMAKE_XCODE_ORGANIZATIONNAME.

2015-08-27 Thread Brad King
On 08/25/2015 01:00 PM, Cody Krieger wrote:
>> //  Created by Joe Schmoe on 8/25/15.
>> //  Copyright (c) 2015 My Company, Inc. All rights reserved.

CMake-generated Xcode project files are not meant for redistribution.
What other effects does such a notice have?  Does it appear in the
IDE somewhere?

> I tried to adhere to the surrounding coding style and whatnot.
> Let me know if anything needs massaging.

The change itself looks good.  Please also add a

 Help/variable/CMAKE_XCODE_ORGANIZATIONNAME.rst

file with documentation.  Also reference it from

 Help/manual/cmake-variables.7.rst

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


Re: [cmake-developers] OSX - Application bundle and private frameworks?

2015-08-27 Thread Brad King
On 08/25/2015 10:29 AM, Raffi Enficiaud wrote:
> Thank you for the feedback (and sorry for the late reply). However I 
> could not find any example of this fixup_bundle, and I find that quite 
> complicated just to copy a directory to the bundle itself.

See the bottom of Source/QtDialog/CMakeLists.txt for an example call
to fixup_bundle.

> Do you have any good example of use?
> OTOH I may have a look to the other option of having a different 
> behaviour for MACOSX_PACKAGE_LOCATION (looks like the behaviour is in 
> cmGlobalXCodeGenerator.cxx, lines 1249+).

This may be reasonable to implement anyway if only for consistency
with the behavior exhibited when using the Xcode generator.

-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] ExternalProject: Use native paths as substitute for directory tokens

2015-08-27 Thread Brad King
On 08/26/2015 03:35 AM, Kislinskiy, Stefan wrote:
> Would you prefer to have a switch for each *_DIR variable for all
> target steps, or a common switch but for each target step, like
> the new USE_TERMINAL switches in the master?
[snip]
> Von: CHEVRIER, Marc [marc.chevr...@sap.com]
> Offering the possibility to manage native paths in an easy way
> is a very good enhancement

Another approach is to introduce a generator expression to transform
the path slash style.  Then it could be used both for ExternalProject
and in other custom commands.  E.g.

 $/bootstrap${shell_ext}>

In this case  would be replaced with forward slashes
by ExternalProject but then at generate time CMake would evaluate
the genex to convert slashes as needed.

-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] FindZLIB module should find debug and, release variants

2015-08-27 Thread Brad King
On 08/25/2015 04:39 PM, Michael Scott wrote:
> I'm assuming that there should be a IMPORTED_LOCATION property defined 
> in all cases as well?

No, there doesn't need to be.  Once IMPORTED_CONFIGURATIONS is populated
then we expect each configuration to have an IMPORTED_LOCATION_
setting too.  CMake will choose an appropriate configuration and use
that location.

-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] CTest XML outputs unsafe content

2015-08-27 Thread Mathieu MARACHE
Hi there,

I'm maintaining a CTest output parser for Bamboo. It was reported to me
that CMake 3.3.1 produced parsing issues in my plugin. After digging into
CMake source code, it seems that a bug was introduced with the replacement
of direct use of cmXMLSafe and std::ostream in favor of cmXMLwriter.

cmXMLWriter is, I assume wrongly, output Safe content without (quotes,
etc.) escaping.

This simple modification corrects this to have pre-3.3 area behavior :

index c38c0de..7b71bae 100644
--- a/Source/cmXMLWriter.h
+++ b/Source/cmXMLWriter.h
@@ -94,12 +94,12 @@ private:

   static cmXMLSafe SafeContent(const char* value)
 {
-return cmXMLSafe(value).Quotes(false);
+return cmXMLSafe(value);
 }

   static cmXMLSafe SafeContent(std::string const& value)
 {
-return cmXMLSafe(value).Quotes(false);
+return cmXMLSafe(value);
 }

   template 

Regards,
--
nǝıɥʇɐƜ


0001-escape-quotes.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

Re: [cmake-developers] Is there an official FindMKL module?

2015-08-27 Thread Siebren Reker
Hi Tim,

Quick add-on to my previous email. With BLA_STATIC ON, I see from the
CMakeError.log that the static libraries ARE found (I was trusting the),
but the linking of the test program goes wrong:
undefined reference to `mkl_blas_sgemv`
But that function IS implemented in one of the three libraries that is
found, in my case in libmkl_sequential.a

So this is probably a linking/ library ordering error.
Indeed, Intel fora and the link advisor I mentioned earlier also report the
need for grouping these as in
 -Wl,--start-group ${MKLROOT}/lib/intel64/libmkl_intel_lp64.a
${MKLROOT}/lib/intel64/libmkl_core.a
${MKLROOT}/lib/intel64/libmkl_sequential.a -Wl,--end-group

Is my understanding correct, and can this be fixed?

kind regards,
Siebren


On Thu, Aug 27, 2015 at 11:50 AM, Siebren Reker 
wrote:

> Hi Tim,
>
> That is encouraging, thanks. I went back and tried harder this time, when
> I specified BLA_VENDOR precisely and leave BLA_STATIC off, I am able to get
> to the correct versions.
> In the very same directory where the shared libraries are found, I have
> the static libraries as well, but BLA_STATIC on in that case does not find
> the libraries.
>
> I've read up a bit on this now, so maybe the following information is
> helpful:
> This is a CMake 3.3.0 installation
> My project has both C and Fortran enabled
> I call it as follows:
>
> set( BLA_STATIC ON)
> set( BLA_VENDOR "Intel10_64lp_seq")
> find_package( BLAS )
>
> Is BLA_STATIC = ON working for you?
>
> A separate question I have is if the linker command that will be produced
> afterwards is of course different from the one supplied by Intel in their
> tool. Should that not concern me?
>
> kind regards,
> Siebren
>
>
> On Wed, Aug 26, 2015 at 4:59 PM, Tim Gallagher 
> wrote:
>
>> We sometime struggled to get it working, but we never had to resort to
>> using a FindMKL -- FindBLAS and FindLAPACK work just fine for us, provided
>> we do things "correctly."
>>
>> So long as we have sourced the mklvars script that ships with Intel MKL
>> and we put:
>>
>> BLA_VENDOR=Intel10_64lp_seq ccmake /path/to/source/dir
>>
>>
>> Then everything works fine and we have no issues. So we have to give
>> CMake a hint that we want to pick the Intel version rather than the generic
>> one (and we're using the sequential, 64bit MKL -- if you look in FindBLAS
>> you can see other vendor types).
>>
>> Have you had things fail when you setup your environment variables using
>> the scripts Intel provides and when you set the BLA_VENDOR hint as an
>> environment variable?
>>
>> Tim
>>
>> --
>> *From: *"Siebren Reker" 
>> *To: *cmake-developers@cmake.org
>> *Sent: *Wednesday, August 26, 2015 10:18:44 AM
>> *Subject: *[cmake-developers] Is there an official FindMKL module?
>>
>>
>> Hello,
>>
>> I am using the find_package() command to load settings for the Intel Math
>> Kernel Library (MKL). This works through a custom FindMKL.cmake module that
>> I've made for myself.
>>
>> However, when looking at:
>> https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/
>> I can tell that what I've done is likely only correct for my specific
>> case, and certainly not robust against library version changes and various
>> other changes (openmp, static vs dynamic linking etc.).
>>
>> Instead of a FindMKL.cmake module, an alternative is to have MKL be
>> discovered in the FindBLAS or FindLAPACK modules, but according to what I
>> can find on the bug tracker, that solution is also in a fairly broken state:
>> Bug 14138: http://www.cmake.org/Bug/view.php?id=14138
>> Bug 13543: http://www.cmake.org/Bug/view.php?id=13543
>> Bug 13528: http://www.cmake.org/Bug/view.php?id=13528
>>
>> Google tells me that many people have (like me) created their own
>> FindMKL.cmake module, which are equally specific and tailored.
>>
>> Is anyone aware of a more "official" FindMKL module available somewhere,
>> or at least something that is being somewhat maintained, either by someone
>> at Kitware or Intel? Or of a plan to develop something like that?
>>
>> kind regards,
>> Siebren Reker
>>
>> --
>>
>> 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
>>
>>
>
-- 

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 
informat

Re: [cmake-developers] Is there an official FindMKL module?

2015-08-27 Thread Siebren Reker
Hi Tim,

That is encouraging, thanks. I went back and tried harder this time, when I
specified BLA_VENDOR precisely and leave BLA_STATIC off, I am able to get
to the correct versions.
In the very same directory where the shared libraries are found, I have the
static libraries as well, but BLA_STATIC on in that case does not find the
libraries.

I've read up a bit on this now, so maybe the following information is
helpful:
This is a CMake 3.3.0 installation
My project has both C and Fortran enabled
I call it as follows:

set( BLA_STATIC ON)
set( BLA_VENDOR "Intel10_64lp_seq")
find_package( BLAS )

Is BLA_STATIC = ON working for you?

A separate question I have is if the linker command that will be produced
afterwards is of course different from the one supplied by Intel in their
tool. Should that not concern me?

kind regards,
Siebren


On Wed, Aug 26, 2015 at 4:59 PM, Tim Gallagher 
wrote:

> We sometime struggled to get it working, but we never had to resort to
> using a FindMKL -- FindBLAS and FindLAPACK work just fine for us, provided
> we do things "correctly."
>
> So long as we have sourced the mklvars script that ships with Intel MKL
> and we put:
>
> BLA_VENDOR=Intel10_64lp_seq ccmake /path/to/source/dir
>
>
> Then everything works fine and we have no issues. So we have to give CMake
> a hint that we want to pick the Intel version rather than the generic one
> (and we're using the sequential, 64bit MKL -- if you look in FindBLAS you
> can see other vendor types).
>
> Have you had things fail when you setup your environment variables using
> the scripts Intel provides and when you set the BLA_VENDOR hint as an
> environment variable?
>
> Tim
>
> --
> *From: *"Siebren Reker" 
> *To: *cmake-developers@cmake.org
> *Sent: *Wednesday, August 26, 2015 10:18:44 AM
> *Subject: *[cmake-developers] Is there an official FindMKL module?
>
>
> Hello,
>
> I am using the find_package() command to load settings for the Intel Math
> Kernel Library (MKL). This works through a custom FindMKL.cmake module that
> I've made for myself.
>
> However, when looking at:
> https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/
> I can tell that what I've done is likely only correct for my specific
> case, and certainly not robust against library version changes and various
> other changes (openmp, static vs dynamic linking etc.).
>
> Instead of a FindMKL.cmake module, an alternative is to have MKL be
> discovered in the FindBLAS or FindLAPACK modules, but according to what I
> can find on the bug tracker, that solution is also in a fairly broken state:
> Bug 14138: http://www.cmake.org/Bug/view.php?id=14138
> Bug 13543: http://www.cmake.org/Bug/view.php?id=13543
> Bug 13528: http://www.cmake.org/Bug/view.php?id=13528
>
> Google tells me that many people have (like me) created their own
> FindMKL.cmake module, which are equally specific and tailored.
>
> Is anyone aware of a more "official" FindMKL module available somewhere,
> or at least something that is being somewhat maintained, either by someone
> at Kitware or Intel? Or of a plan to develop something like that?
>
> kind regards,
> Siebren Reker
>
> --
>
> 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
>
>
-- 

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] Use dllexport and dllimport on Cygwin too

2015-08-27 Thread Tony Kelman
First hunk below is from Yaakov Selkowitz, it was reported to be 
necessary to build KF5 in Cygwin. Second hunk fixes the corresponding 
test to account for the change. Currently the MinGW platform reference 
outputs appear to match the Cygwin results here, though a separate new 
pair of reference outputs just for Cygwin could of course work for this 
too.

Thanks,
Tony


diff --git a/Modules/GenerateExportHeader.cmake 
b/Modules/GenerateExportHeader.cmake
index aab29ea..8205425 100644
--- a/Modules/GenerateExportHeader.cmake
+++ b/Modules/GenerateExportHeader.cmake
@@ -268,7 +268,7 @@ macro(_DO_SET_MACRO_VALUES TARGET_LIBRARY)
   get_property(type TARGET ${TARGET_LIBRARY} PROPERTY TYPE)

   if(NOT ${type} STREQUAL "STATIC_LIBRARY")
-if(WIN32)
+if(WIN32 OR CYGWIN)
   set(DEFINE_EXPORT "__declspec(dllexport)")
   set(DEFINE_IMPORT "__declspec(dllimport)")
 elseif(COMPILER_HAS_HIDDEN_VISIBILITY AND 
USE_COMPILER_HIDDEN_VISIBILITY)
diff --git a/Tests/Module/GenerateExportHeader/CMakeLists.txt 
b/Tests/Module/GenerateExportHeader/CMakeLists.txt
index b52c44d..8cd25a4 100644
--- a/Tests/Module/GenerateExportHeader/CMakeLists.txt
+++ b/Tests/Module/GenerateExportHeader/CMakeLists.txt
@@ -106,10 +106,10 @@ endif()
 add_executable(GenerateExportHeader exportheader_test.cpp)

 target_link_libraries(GenerateExportHeader ${link_libraries})
-if (WIN32)
+if (WIN32 OR CYGWIN)
   if(MSVC AND COMPILER_HAS_DEPRECATED)
 set(_platform Win32)
-  elseif(MINGW AND COMPILER_HAS_DEPRECATED)
+  elseif((MINGW OR CYGWIN) AND COMPILER_HAS_DEPRECATED)
 set(_platform MinGW)
   else()
 set(_platform WinEmpty)


-- 

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