Re: [cmake-developers] Changes for v3.5.0

[Alan W. Irwin]

On 2016-02-09 13:50-0500 Brad King wrote:


On 02/09/2016 01:00 PM, James Bigler wrote:

Will changes integrated into master automatically be slated for either
v3.5.0 RC2 or v.3.5.0 final?


No, the development window for 3.5 closed on Feb 1:

https://cmake.org/pipermail/cmake-developers/2016-February/027637.html


Hi Brad:

So what branch should we follow if we want to test the on-going 3.5.x
effort?

I assumed it would be "release", but one of the key fixes to 3.5.0-rc1
is the efficiency one from my perspective, but I cannot find either
"Fix internal target lookup performance regression" or "Improve
internal generator target structure lookup" at
.
Are those changes being "cooked" a bit longer or are they already in
the release branch under some different title?

Alan
__
Alan W. Irwin

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

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

Linux-powered Science
__
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Changes for v3.5.0

[Brad King]

On 02/09/2016 02:39 PM, Alan W. Irwin wrote:
> So what branch should we follow if we want to test the on-going 3.5.x
> effort?
> 
> I assumed it would be "release"

Yes.  I just merged several of the fixes there this morning.

> but one of the key fixes to 3.5.0-rc1 is the efficiency one
[snip]
> Are those changes being "cooked" a bit longer or are they already in
> the release branch under some different title?

They are cooking in 'master' for few days.  This will give Bartosz
(who reported the performance problem) some time to confirm the fixes
work.

The fixes are also available in the nightly binaries since those
are built from 'next'.

-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] [CMake 0015962]: can't unzip jar file on windows

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15962 
== 
Reported By:nitroamos
Assigned To:
== 
Project:CMake
Issue ID:   15962
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   low
Status: new
== 
Date Submitted: 2016-02-09 15:00 EST
Last Modified:  2016-02-09 15:00 EST
== 
Summary:can't unzip jar file on windows
Description: 
I'd like to use cmake to unpack a .jar file. To do this, I use the following
command in my CMakeLists.txt:

execute_process(COMMAND ${CMAKE_COMMAND} -E tar xf ${MY_JAR} --format=zip
${CMAKE_CURRENT_BINARY_DIR}/ )


Which I run through the CMake GUI. This command works as intended on OSX. On
Windows, I get the following error when configuring:


COMMAND C:/Program Files (x86)/CMake/bin/cmake.exe -E tar xf my.jar --format=zip
build
CMake Error: Problem with archive_write_header(): Can't create '\\?\C:\Program
Files (x86)\CMake\META-INF\MANIFEST.MF'

CMake Error: Current file: META-INF/MANIFEST.MF

CMake Error: Problem extracting tar: my.jar



Steps to Reproduce: 
cmake_minimum_required(VERSION 2.8.9)
project(extractjar)

message("COMMAND ${CMAKE_COMMAND} -E tar xf ${CMAKE_SOURCE_DIR}/my.jar
--format=zip ${CMAKE_CURRENT_BINARY_DIR}/")
execute_process(COMMAND ${CMAKE_COMMAND} -E tar xf ${CMAKE_SOURCE_DIR}/my.jar
--format=zip ${CMAKE_CURRENT_BINARY_DIR}/ )
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-02-09 15:00 nitroamos  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] Question related to Visual Studio 14 2015 [MyTarget]

[Ian Henriksen]

On Tue, Feb 9, 2016 at 10:15 AM Gilles Khouzam 
wrote:

> I'm trying to understand what is necessary to make this work. I'll circle
> back when I find out more information.
>
> -Original Message-
> From: Brad King [mailto:brad.k...@kitware.com]
> Sent: Monday, February 8, 2016 10:32
> To: Yi-Hong Lyu 
> Cc: cmake-developers@cmake.org; Gilles Khouzam <
> gilles.khou...@microsoft.com>
> Subject: Re: [cmake-developers] Question related to Visual Studio 14 2015
> [MyTarget]
>
> On 02/05/2016 02:41 PM, Yi-Hong Lyu wrote:
> > 1. What I need to do is to add an option MyTarget for arch of "Visual
> > Studio 14 2015 [arch]", just like "Visual Studio 14 2015 [Win64]"
> > or "Visual Studio 14 2015 [ARM]"?
>
> Naming the architecture as part of the generator name is a legacy behavior.
> See the "-A " option.
>
> > 2. How can I support cl.exe and clang-cl.exe by Visual Studio 14 2015
> [MyTarget]"?
> > Should I add options cl.exe/clang-cl.exe for toolset-name of "-T
> "?
>
> The -T option is indeed the CMake side of it.  I'm not familiar with what
> else has to be done on the host to make VS understand the toolset name
> though.
>
> > 3. Is there any way to make sure that all x86/x64 headers/libraries are
> not included/linked?
> > I'd like only include/link headers/libraries of MyTarget.
>
> CMake doesn't add any system include directories or link directories.  For
> command line builds those need to be part of the environment.  For VS IDE
> builds they are made available by the IDE when running the toolchain based
> on the options discussed above.
>

I've been experimenting with this lately. When building with NMake, adding
the
flag "-fms-compatibility-version=19.00.23506" got clang to act like the
right version
of MSVC. MSVC 2013 is the default right now.
When building with the generator "Visual Studio 14 2015 Win64", adding the
toolset
flag "-TLLVM-vs2014" got clang to work.
https://github.com/boostorg/hana/wiki/Setting-up-Clang-on-Windows was really
helpful in figuring some of this out.
All that aside, seamless interaction between clang-cl and MSVC 2015 is
definitely
still a work in progress.

Best,
-Ian Henriksen


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

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] FindProtobuf: check version

[Antonio Pérez Barrero]

>
> > +  math(EXPR Protobuf_MAJOR_VERSION "${Protobuf_VERSION} / 100")
> > +  math(EXPR Protobuf_MINOR_VERSION "${Protobuf_VERSION} / 1000 % 1000")
> > +  math(EXPR Protobuf_SUBMINOR_VERSION "${Protobuf_VERSION} % 1000")
>
> Would string manipulation be better here?


I don't know how to make it better. I took FindBoost.cmake code as template
here. Which could be a better way?

Thanks,
Antonio
-- 

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] FindProtobuf: fix wrong library list for Unix

[Antonio Pérez Barrero]

>
> On 02/08/2016 04:24 PM, Antonio Pérez Barrero wrote:
> > Yes, it is possible, but currently it's not looking for the debug
> > library with a different name, just in a different path that is
> > unlikely to exist in a Unix system.
>
> The fact that a separate find_library is called for it and the result
> is stored in a separate (user-settable) cache entry means that it is
> possible to get two different values.  This convention is well established
> in several find modules.
>
> > Having the PROTOBUF_LIBRARIES variable getting the afore mentioned
> > value messes up the client code using `find_package(Protobuf)` on Unix.
>
> The only supported use for PROTOBUF_LIBRARIES is to pass it to
> target_link_libraries, and that interprets the 'optimized' and 'debug'
> keywords.  This is shown in the module documentation example:
>
> target_link_libraries(bar ${PROTOBUF_LIBRARIES})
>
> The documentation makes no other guarantees about the variable value.
>

Thanks for your explanantion, that makes sense. I had issues because I was
appending the value of PROTOBUF_LIBRARIES to a list and then removing
duplicates before calling `target_link_libraries(bar ${LIST})`. So when the
PROTOBUF_LIBRARIES values was
`optimized;/usr/lib/libprotobuf.so;debug;/usr/lib/libprotobuf.so` I was
missing the link flag for /usr/lib/libprotobuf.so in Debug builds. Skipping
the duplicates removal step solves my issue.

Anyway, the root cause is the `find_library` is finding the same library
for optimized and debug configuration. So, would a patch like this be
benefial?

diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake
index 2f13b09..35929a4 100644
--- a/Modules/FindProtobuf.cmake
+++ b/Modules/FindProtobuf.cmake
@@ -224,7 +224,7 @@ function(_protobuf_find_libraries name filename)
PATHS
${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug)
mark_as_advanced(${name}_LIBRARY_DEBUG)

-   if(NOT ${name}_LIBRARY_DEBUG)
+   if((NOT ${name}_LIBRARY_DEBUG) OR (${name}_LIBRARY STREQUAL
${name}_LIBRARY_DEBUG))
   # There is no debug library
   set(${name}_LIBRARY_DEBUG ${${name}_LIBRARY} PARENT_SCOPE)
   set(${name}_LIBRARIES ${${name}_LIBRARY} PARENT_SCOPE)

---

Thanks,
Antonio
-- 

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] FindProtobuf: fix wrong library list for Unix

[Rolf Eike Beer]

Am 09.02.2016 11:10, schrieb Antonio Pérez Barrero:


On 02/08/2016 04:24 PM, Antonio Pérez Barrero wrote:
> Yes, it is possible, but currently it's not looking for the debug
> library with a different name, just in a different path that is
> unlikely to exist in a Unix system.

The fact that a separate find_library is called for it and the result
is stored in a separate (user-settable) cache entry means that it is
possible to get two different values.  This convention is well 
established

in several find modules.

> Having the PROTOBUF_LIBRARIES variable getting the afore mentioned
> value messes up the client code using `find_package(Protobuf)` on Unix.

The only supported use for PROTOBUF_LIBRARIES is to pass it to
target_link_libraries, and that interprets the 'optimized' and 'debug'
keywords.  This is shown in the module documentation example:

target_link_libraries(bar ${PROTOBUF_LIBRARIES})

The documentation makes no other guarantees about the variable value.



Thanks for your explanantion, that makes sense. I had issues because I 
was

appending the value of PROTOBUF_LIBRARIES to a list and then removing
duplicates before calling `target_link_libraries(bar ${LIST})`. So when 
the

PROTOBUF_LIBRARIES values was
`optimized;/usr/lib/libprotobuf.so;debug;/usr/lib/libprotobuf.so` I was
missing the link flag for /usr/lib/libprotobuf.so in Debug builds. 
Skipping

the duplicates removal step solves my issue.

Anyway, the root cause is the `find_library` is finding the same 
library

for optimized and debug configuration. So, would a patch like this be
benefial?

diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake
index 2f13b09..35929a4 100644
--- a/Modules/FindProtobuf.cmake
+++ b/Modules/FindProtobuf.cmake
@@ -224,7 +224,7 @@ function(_protobuf_find_libraries name filename)
PATHS
${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug)
mark_as_advanced(${name}_LIBRARY_DEBUG)

-   if(NOT ${name}_LIBRARY_DEBUG)
+   if((NOT ${name}_LIBRARY_DEBUG) OR (${name}_LIBRARY STREQUAL
${name}_LIBRARY_DEBUG))
   # There is no debug library
   set(${name}_LIBRARY_DEBUG ${${name}_LIBRARY} PARENT_SCOPE)
   set(${name}_LIBRARIES ${${name}_LIBRARY} PARENT_SCOPE)


Just use SelectLibraryConfigurations, that does the same automatically 
if they are identical, and also handles the cases where only debug, but 
not release is found.


Greetings,

Eike
--

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] Drop support for older Xcode versions?

[Davy Durham]

I'll say that in my line of work, we still have to support OS X 10.6 
(just dropped 10.5 support) .. And we're doing this at Apple's own 
request/demand!  It's not fun.  I've had to hack tools around to get 
somewhat newer tool chains to continue to work, but it's been /great/ 
that cmake hasn't been an obstacle in this endeavour.






On 02/08/2016 11:48 PM, Tim Blechmann wrote:

Given Apple's encouragement of developers to always update...

They certainly do, as Eric described.  However, just like everyone
else, Apple often ships regressions in Xcode and it's sometimes vital
to be able to use older versions.  Similarly, if you want to deploy
an app to an older OS, it's very useful to be able to build-run-debug
on that OS, and since the newest Xcodes only run on the newest OSes,
one needs an older Xcode to test/debug on older OSes.

if a project relies on an old xcode version, does it need to use the
most up-to-date cmake? also, there are always make/ninja generators ...




-- 

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 0015961]: CMake Regex does not support lookahead regular expressions.

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15961 
== 
Reported By:raffael casagrande
Assigned To:
== 
Project:CMake
Issue ID:   15961
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-02-09 08:14 EST
Last Modified:  2016-02-09 08:14 EST
== 
Summary:CMake Regex does not support lookahead regular
expressions.
Description: 
Trying to use a Regular expression that contains a lookahead clause is not
supported by CMake. 

Steps to Reproduce: 
Try to execute the following CMake statement:
string(REGEX MATH "(?!red|green|blue)" _bla ${CMAKE_CURRENT_LIST_DIR})

It will fail with:

 string sub-command REGEX, mode REPLACE failed to compile regex
  "(?!red|green|blue)".
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-02-09 08:14 raffael casagrandeNew 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] Drop support for older Xcode versions?

[Davy Durham]

I should also have mentioned that we're supporting a number of other 
platforms at the same time.. hence our use of cmake.  And would rather 
not have to maintain cmake files that are lowest-common-denominator for 
the version of cmake that has to continue working on OS X 10.6


On 02/09/2016 08:49 AM, Davy Durham wrote:
I'll say that in my line of work, we still have to support OS X 10.6 
(just dropped 10.5 support) .. And we're doing this at Apple's own 
request/demand!  It's not fun.  I've had to hack tools around to get 
somewhat newer tool chains to continue to work, but it's been /great/ 
that cmake hasn't been an obstacle in this endeavour.






On 02/08/2016 11:48 PM, Tim Blechmann wrote:

Given Apple's encouragement of developers to always update...

They certainly do, as Eric described.  However, just like everyone
else, Apple often ships regressions in Xcode and it's sometimes vital
to be able to use older versions.  Similarly, if you want to deploy
an app to an older OS, it's very useful to be able to build-run-debug
on that OS, and since the newest Xcodes only run on the newest OSes,
one needs an older Xcode to test/debug on older OSes.

if a project relies on an old xcode version, does it need to use the
most up-to-date cmake? also, there are always make/ninja generators ...








-- 

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] Question related to Visual Studio 14 2015 [MyTarget]

[Gilles Khouzam]

I'm trying to understand what is necessary to make this work. I'll circle back 
when I find out more information.

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Monday, February 8, 2016 10:32
To: Yi-Hong Lyu 
Cc: cmake-developers@cmake.org; Gilles Khouzam 
Subject: Re: [cmake-developers] Question related to Visual Studio 14 2015 
[MyTarget]

On 02/05/2016 02:41 PM, Yi-Hong Lyu wrote:
> 1. What I need to do is to add an option MyTarget for arch of "Visual 
> Studio 14 2015 [arch]", just like "Visual Studio 14 2015 [Win64]"
> or "Visual Studio 14 2015 [ARM]"?

Naming the architecture as part of the generator name is a legacy behavior.
See the "-A " option.

> 2. How can I support cl.exe and clang-cl.exe by Visual Studio 14 2015 
> [MyTarget]"?
> Should I add options cl.exe/clang-cl.exe for toolset-name of "-T 
> "?

The -T option is indeed the CMake side of it.  I'm not familiar with what else 
has to be done on the host to make VS understand the toolset name though.

> 3. Is there any way to make sure that all x86/x64 headers/libraries are not 
> included/linked?
> I'd like only include/link headers/libraries of MyTarget.

CMake doesn't add any system include directories or link directories.  For 
command line builds those need to be part of the environment.  For VS IDE 
builds they are made available by the IDE when running the toolchain based on 
the options discussed above.

-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] FeatureSummary and Fortran

[Brad King]

On 02/08/2016 10:35 AM, Alin Marin Elena wrote:
> I was playing to day with FeatureSummary and Fortran and I discovered the two 
> do not like each other too much . While MPI is obviously found in here... 
> Feature summary claims it did not
> 
> -- Found MPI_Fortran: /opt/openmpi/gcc/1.10.1/lib64/libmpi_usempif08.so;/opt/
> openmpi/gcc/1.10.1/lib64/libmpi_usempi_ignore_tkr.so;/opt/openmpi/gcc/1.10.1/
> lib64/libmpi_mpifh.so;/opt/openmpi/gcc/1.10.1/lib64/libmpi.so  

Technically it was "MPI_Fortran" that was found.  It looks like FindMPI
distinguishes each of the languages as a kind of sub-package:

 
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindMPI.cmake;hb=v3.4.3#l14

This is different from most other find modules because the results
need to be language-specific.

The actual MPI_FOUND variable is set only based on MPI_CXX_FOUND or
MPI_C_FOUND for compatibility with when there was no language distinction:

 
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindMPI.cmake;hb=v3.4.3#l620

I think MPI_Fortran_FOUND was left out of that because there was no support
for Fortran MPI originally and this language distinction was added as part
of adding support for Fortran.  I was not involved with that development
process myself so I do not know for sure.

One could look at updating the code to treat setting MPI_FOUND as an
official result (as needed by find_package with REQUIRED) rather than only
for compatibility.  This would mean reconciling MPI_C_FOUND, MPI_CXX_FOUND,
and MPI_Fortran_FOUND.  I'm not sure the proper approach because we do not
know which languages the caller actually needs.

-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] [CMake 0015963]: strange behaviour running readlink via execute_process

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15963 
== 
Reported By:Bruce Adams
Assigned To:
== 
Project:CMake
Issue ID:   15963
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-02-09 16:52 EST
Last Modified:  2016-02-09 16:52 EST
== 
Summary:strange behaviour running readlink via
execute_process
Description: 
I'm trying to use readlink -f to get the absolute path to a shared library
following all symlinks.

>readlink -f /opt/gcc4.9.3/lib64/libstdc++.so.6
/opt/gcc4.9.3/lib64/libstdc++.so.6.0.20

but when I do this in cmake it doesn't expand the full path E.g.

set(CPP11_PATH ${CMAKE_CURRENT_BINARY_DIR}/)
execute_process(COMMAND ldd ${CPP11_PATH} COMMAND grep libstdc++ COMMAND awk "{
print $3; }" OUTPUT_VARIABLE LIBSTDCPP_PATH)
message("LIBSTDCPP_PATH=${LIBSTDCPP_PATH}")
execute_process(COMMAND readlink -f ${LIBSTDCPP_PATH} OUTPUT_VARIABLE
LIBSTDCPP_ABSPATH)
message("LIBSTDCPP_ABSPATH=${LIBSTDCPP_ABSPATH}")

prints:

LIBSTDCPP_PATH=/opt/gcc4.9.3/lib64/libstdc++.so.6
LIBSTDCPP_ABSPATH=/opt/gcc4.9.3/lib64/libstdc++.so.6

This also happens if I wrap it in a shell script:

execute_process(COMMAND doreadlink.sh ${LIBSTDCPP_PATH} OUTPUT_VARIABLE
LIBSTDCPP_ABSPATH2)
message("LIBSTDCPP_ABSPATH2=${LIBSTDCPP_ABSPATH2}")

>LIBSTDCPP_ABSPATH2=/opt/gcc4.9.3/lib64/libstdc++.so.6




Steps to Reproduce: 
cmake_minimum_required(VERSION 2.8)
project(TEST CXX) 
CMake script as below

set(CPP11_PATH ${CMAKE_CURRENT_BINARY_DIR}/cpp11)
execute_process(COMMAND g++ ${CMAKE_CURRENT_SOURCE_DIR}/cpp11.cpp
-o${CPP11_PATH})

execute_process(COMMAND ldd ${CPP11_PATH} COMMAND grep libstdc++ COMMAND awk "{
print $3; }" OUTPUT_VARIABLE LIBSTDCPP_PATH)
message("LIBSTDCPP_PATH=${LIBSTDCPP_PATH}")
execute_process(COMMAND readlink -f ${LIBSTDCPP_PATH} OUTPUT_VARIABLE
LIBSTDCPP_ABSPATH)
message("LIBSTDCPP_ABSPATH=${LIBSTDCPP_ABSPATH}")

Additional Information: 
The following is an effective work around

execute_process(COMMAND ldd ${CPP11_PATH} COMMAND grep libstdc++ COMMAND awk "{
print $3; }" COMMAND xargs readlink -f OUTPUT_VARIABLE LIBSTDCPP_PATH)

Originally raised on stackoverflow:

http://stackoverflow.com/questions/35299970/strange-behaviour-with-readlink-under-cmake
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-02-09 16:52 Bruce AdamsNew 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] Changes for v3.5.0

[Brad King]

On 02/09/2016 01:00 PM, James Bigler wrote:
> Will changes integrated into master automatically be slated for either
> v3.5.0 RC2 or v.3.5.0 final?

No, the development window for 3.5 closed on Feb 1:

 https://cmake.org/pipermail/cmake-developers/2016-February/027637.html

-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] Developer tasks - Daemon mode

[Stephen Kelly]

The Daemon mode for CMake is online here:

 https://github.com/steveire/CMake/tree/cmake-daemon

The commit messages and some of the commits contain indications of things 
that need to be done before such a mode could be introduced into CMake, such 
as writing a new failsafe parser and implementing some of the features in 
the branch so that they work well in all cases.

I won't repeat those tasks in a list here, but they prevent the Daemon from 
becoming upstreamable.

There are other tasks which prevent the Daemon being upstreamable to cmake 
proper. These are not tasks for raw-beginners:

1) Using libuv filesystem notification to re-generate the cmState when 
  buildsystem files change (and notifying the client through the protocol
  about resulting changes in the generated buildsystem).  This is by far the 
  most essential.

2) Prune state which is created while operating. The parts of the protocol 
  which execute some cmake code (eg, debugging and code completion) create 
  cmState::Snapshots without cleaning them up afterward (or possibly using 
  an LRU cache if such a thing would make sense).


I can provide guidance to anyone wishing to complete them, or any of the 
tasks described in the cmake-daemon branch.

Thanks,

Steve.


-- 

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 Daemon

[Stephen Kelly]

Stephen Kelly wrote:

> Tamás Kenéz wrote:
> 
>> That's great and really does open a new world for IDEs!
> 
> Thanks! Let's see if the interest grows.
> 
> I've just pushed the daemon code here:
> 
>  https://github.com/steveire/cmake/tree/cmake-daemon

Tobias made a pull request there. Rather than review it there, I will review 
it here for visibility.

 https://github.com/steveire/CMake/pull/2

The branch is quite it hard to review, or even to see the particular 
changes, due to large commits and diff noise. If the Daemon reaches a level 
of completeness that it could be upstreamed (See 

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15740

) then these commits (including all of my commits on the branch) would have 
to be rewritten, split, made reviewable etc making heavy use of `rebase -i`. 

In a way, we don't have to do that now, but I'm also not very enthusiastic 
about making the `cmake-daemon` branch commits unreadable. I would add your 
commits to the branch if they we split and in the appropriate place (eg, 
with the cmServerProtocol0_1 change early in the cmake-daemon branch).

The changes in your branch are good and useful to more than just QtCreator.

Things that I like in your branch:

* Explicit cmServerRequest and cmServerResponse APIs, which enforce the type 
and cookie consistency. 
* Returning cmServerResponse objects from the cmServerProtocol instead of 
invoking the server from the cmServerProtocol. 
* A way to version the protocol in a future-proof way with C++ classes.
* Implementation of daemon and protocol error messaging infrastructure. 
(Reporting errors from cmake code requires other refactoring: 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15607/focus=15636)

So I think that is progress!

Thanks,

Steve.



-- 

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

[Stephen Kelly]

Stephen Kelly wrote:

> Hi,
> 
> I just made a blog and video about the advanced features and possibilities
> that a daemon mode for CMake can bring:
> 
>  https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/
> 


The lack of response on the list to any of this is quite disappointing.

-- 

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] Developer tasks - Refactoring

[Stephen Kelly]

In order to make it possible to implement fully featured user tools like the 
cmake daemon

 https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/

... and to make it possible to use multiple toolchains at once

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7272

... and turn CMake into a fully capable modern cross-compiling buildsystem

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10873

... the implementation of CMake needs to improve. At least if any of those 
advanced features are to be maintainable.

A large amount of the steps to get there involve refactoring the existing 
CMake code to be more flexible. I have been doing that since April last 
year, but I want to open up the task list to other collaborators and 
newcomers in particular.

Here are some entry-level refactoring tasks which have a useful impact on 
CMake, and which lead to more familiarity with the code for whoever does 
them. Feel free to ask for further guidance on any task.

1) Make cmLocalGenerator not inherit cmOutputConverter
* Change enums like cmLocalGenerator::START_OUTPUT with sed.  See

   https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eac15298

  for a similar sed command to achieve this.

* Remove inheritance. Implement Convert() methods in cmLocalGenerator for 
  source compatibility which instantiate and use a cmOutputConverter as in

   https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4d8b79ad

2) Reduce generate-time use of cmMakefile definitions
* The intention is to remove direct use of cmMakefile from generate-time 
  code.
* Use an IDE to find uses of cmGeneratorTarget::Makefile and 
  cmGeneratorTarget::Target
* Replace use of 'low-level' GetDefinition from cmMakefile with more 
  'high-level' methods on cmGeneratorTarget.  Eg

   this->Target->Target->GetMakefile()->GetDefinition("CMAKE_STRIP")

  in cmComputeLinkInformation could be replaced with a new

   std::string cmGeneratorTarget::GetCMakeStripTool() const;

  or similar.

3) Compute cmGeneratorTarget state non-lazily in its constructor.
* Historically target state for generators was computed lazily because it 
  might need to be cleared and re-computed.  That is no-longer true.
* For example, the LinkInformation is populated lazily in
  cmGeneratorTarget::GetLinkInformation.
* Instead the LinkInformation could be populated in the cmGeneratorTarget 
  constructor for all known configurations.  That is what generators will 
  request during generate-time anyway.
* Doing this will make it possible to split a cmComputedTarget out of 
  cmGeneratorTarget.

Thanks,

Steve.


-- 

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] Changes for v3.5.0

[James Bigler]

Will changes integrated into master automatically be slated for either
v3.5.0 RC2 or v.3.5.0 final?
-- 

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