[cmake-developers] patch for module GetPrerequisites

[Benjamin Ballet]

Hello

We are using fixup_bundle on Windows and I discovered that this function
doesn't work if the path of the app is not in it's canonical form.

Of course I can canonicalize the path of the app but I would like to fix
this issue for everyone.

The fail occurs during verify_app in the function gp_resolved_file_type
from module GetPrerequisites. This function test if two paths are equal
without translating them to there canonical form before.

Here is the patch for this modification

-- 
*Benjamin BALLET*
Ingénieur R

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard Tél* :  01 44 69 37 37
*>* www.activisu.com


0001-GetPrerequisites-function-gp_resolved_file_type-shou.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] C++11 only for a specified subdirectory

[Konstantin Podsvirov]

Hi, Roman!

You can use properties for each target:

C_STANDART
C_STANDARD_REQUIRED

CXX_STANDARD
CXX_STANDARD_REQUIRED

Read online:

https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html#properties-on-targets

And this question is for cm...@cmake.org list :-)

04.03.2016, 16:20, "Roman Wüger" :
> Hi,
>
> is it possible to activate C++11 only for a subdirectory?
>
> Regards
> Roman
> --
>
> 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

Regards,
Konstantin Podsvirov
-- 

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] Appending to LINK_FLAGS property of a target doesn't seem to work correctly

[Dan Liew]

On 3 March 2016 at 22:02, Nils Gladitz  wrote:
> On 03.03.2016 22:57, Dan Liew wrote:
>>
>> Hi,
>>
>> I noticed recently is you do something like this
>>
>> add_executable(foo a.cpp b.cpp)
>> set_property(TARGET shell APPEND PROPERTY LINK_FLAGS "-fopenmp")
>> set_property(TARGET shell APPEND PROPERTY LINK_FLAGS "-static")
>>
>> then the flags that end up being passed to the compiler during linking
>> are like this.
>>
>> gcc -g -O0 -fopenmp;-static
>>
>> It looks like when using the property with APPEND it becomes a list
>> but when emitted the list isn't expanded properly. I noticed this
>> using CMake 3.4.3 using the "Unix Makefile" generator.
>>
>> Is this intentional or is this a bug?
>
>
> LINK_FLAGS is not a list property; flags have to be whitespace separated.
> You can use APPEND_STRING instead of APPEND for this.

Thanks for this. Shouldn't the fact that ``LINK_FLAGS`` is a string
property and not a list property be in the ``cmake-properties``
documentation? The version of the documentation for my version of
CMake (3.4.3) doesn't say what the property type is.

Thanks,
Dan.
-- 

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 0016007]: Visual Studio 2015 + v110_xp toolset + MFC: rerun cmake 3.5.0-rc3 inside Visual Studio breaks compilation

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=16007 
== 
Reported By:Anatoly Shirokov
Assigned To:
== 
Project:CMake
Issue ID:   16007
Category:   CCMake
Reproducibility:always
Severity:   block
Priority:   normal
Status: new
== 
Date Submitted: 2016-03-04 13:47 MSK
Last Modified:  2016-03-04 13:47 MSK
== 
Summary:Visual Studio 2015 + v110_xp toolset + MFC: rerun
cmake 3.5.0-rc3 inside Visual Studio breaks compilation
Description: 
When I change CMakeLists.txt inside Visual Studio 2015 and try to rebuild my
solution, I get complication errors:
Error C2039: 'SetDefaultDllDirectories' : is not a member of '`global
namespace'' c:\program files (x86)\microsoft visual studio
14.0\vc\atlmfc\include\atlcore.h 638 1 
Error C2065: 'SetDefaultDllDirectories' : undeclared identifier c:\program files
(x86)\microsoft visual studio 14.0\vc\atlmfc\include\atlcore.h 638 1 
Error C2065: 'LOAD_LIBRARY_SEARCH_SYSTEM32' : undeclared identifier c:\program
files (x86)\microsoft visual studio 14.0\vc\atlmfc\include\atlcore.h 640 1

Steps to Reproduce: 
1. generate mfc project 

>call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC"\vcvarsall.bat x86

>set PATH=%VCINSTALLDIR%\bin;C:\Program Files (x86)\CMake 3.5\bin;%PATH%;

>cmake --version
cmake version 3.5.0-rc3

>cmake -G "Visual Studio 14 2015" -T v110_xp ..\src

2. open the solution in Visual Studio 2015

3. build the solution without any errors

4. change CMakeLists.txt

5. rebuild the solutions and get errors:
Error C2039: 'SetDefaultDllDirectories' : is not a member of '`global
namespace'' c:\program files (x86)\microsoft visual studio
14.0\vc\atlmfc\include\atlcore.h 638 1 
Error C2065: 'SetDefaultDllDirectories' : undeclared identifier c:\program files
(x86)\microsoft visual studio 14.0\vc\atlmfc\include\atlcore.h 638 1 
Error C2065: 'LOAD_LIBRARY_SEARCH_SYSTEM32' : undeclared identifier c:\program
files (x86)\microsoft visual studio 14.0\vc\atlmfc\include\atlcore.h 640 1


Additional Information: 
I have found the feedback related to this problem:
https://connect.microsoft.com/VisualStudio/feedback/details/773422/compiler-error-when-using-v110-xp-platform-toolset-visual-studio-2012

There is a workaround posted by Wouter_Demuynck on 17.12.2012 at 4:07:
I noticed that selecting the v110_xp toolset in the process properties did not
automatically enable the _USING_V110_SDK71_ preprocessor flag.

After manually adding the following define at the top of my stdafx.h, the
project compiled fine:

#define _USING_V110_SDK71_

I have added #define _USING_V110_SDK71_ to my CMakeFiles.txt, and it solved the
problem, but may be there is more elegance solution? 
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-03-04 13:47 Anatoly ShirokovNew 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 0016006]: Incorrect physical/logical core counts from kwsys on Windows

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=16006 
== 
Reported By:Nils Gladitz
Assigned To:
== 
Project:CMake
Issue ID:   16006
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-03-04 03:24 EST
Last Modified:  2016-03-04 03:24 EST
== 
Summary:Incorrect physical/logical core counts from kwsys on
Windows
Description: 
I am not entirely sure if this is the right place for kwsys issues?

On a Windows 7 64-bit system with two of these:
http://ark.intel.com/products/47922/Intel-Xeon-Processor-X5650-12M-Cache-2_66-GHz-6_40-GTs-Intel-QPI

Hyper-threading is enabled.

In cmsys::SystemInformation
  info.GetNumberOfLogicalCPU() returns 32 (expected is 24)
  info.GetNumberOfPhysicalCPU() returns 0 (expected is 2)

In CMake I exposed these values through 
NUMBER_OF_LOGICAL_CORES and NUMBER_OF_PHYSICAL_CORES in
cmake_host_system_information().

The Windows GetSystemInfo() filled SYSTEM_INFO structure reports 24 in
dwNumberOfProcessors.



Steps to Reproduce: 
cmake_host_system_information(RESULT PHYSICAL_CORES
QUERY NUMBER_OF_PHYSICAL_CORES
)

cmake_host_system_information(RESULT LOGICAL_CORES
QUERY NUMBER_OF_LOGICAL_CORES
)

message("[${PHYSICAL_CORES}:${LOGICAL_CORES}]")

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-03-04 03:24 Nils Gladitz   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