Re: [cmake-developers] Xcode generator is adding old attributes on .pbxproj

2016-02-08 Thread Arnau Quintana 
Hi Gregor,

I am so glad to hear this! :) It will be great to join efforts.

I have used xcproj, and it is kind of a quick and temporal solution for us (and 
maybe others), but I really want to understand all the implications and what 
cmake generates for Xcode projects. 

For instance, I found out that some options are not set up correctly on the 
original pbxproj, and xcproj is not setting up them in the new one. It would be 
better to get cmake set them properly on the first place. :)

About the schemes, that is also a great idea. It would be nice that cmake could 
do that, so people do not need to rely on other tools for the schemes.

It is good to know that there is other people working on this.

Thanks,
Arnau



On 06/02/16 11:42, "Gregor Jasny"  wrote:

>Hello,
>
>some time ago I started a project to make the CMake generated pbxproj
>identical to the one Xcode writes. Some patches of that effort are
>already in master, some lack some cleanup.
>
>It would be great working with you on individual patches to 'modernize'
>generated pbxproj files. Patches would be a superb start.
>
>Note: you could use the xcproj tool to ask Xcode to re-generate the
>project by running "xcproj touch".
>
>I also intend to work on generating schema directly from CMake but this
>will take some time.
>
>Thanks,
>Gregor
-- 

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?

2016-02-08 Thread Sean McBride 
On Mon, 8 Feb 2016 10:31:17 -0500, Brad King said:

>Sean, it looks like you are still running nightly tests on OS X
>10.6 with Xcode 4.2:
>
>  https://open.cdash.org/viewNotes.php?buildid=4226138
>
>and OS X 10.5 with Xcode 3.1:
>
>  https://open.cdash.org/viewNotes.php?buildid=4226202

Yeah, mostly because those machines haven't died either. :)  If/when it's 
decided to drop those Xcodes, I'll switch those builds to makefile generator.

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

Cheers,

-- 

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


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] FindProtobuf: check version

2016-02-08 Thread Ben Boeckel 
On Mon, Feb 08, 2016 at 15:29:50 +, Antonio Pérez Barrero wrote:
> thanks for feedback, I'll rework the patch. I was planning to actually
> submit three patches covering the following:
> 
> * Version checking
> * Interface variables rename, keeping backwards compatibility.
> * Fix a bug when setting Protobuf_LIBRARIES on Un*x systems.

Looks like a sensible breakdown to me.

> So what's the best way to submit them:
> 
> * A separate format-patch for each.

This one.

Sending it as a series of 3 patches is best (and easy if you use git
send-email). Best is that the earlier patches fix bugs and such so that
if they are OK, they're more easily applied independently if later
patches have issues which need resolving yet.

Thanks,

--Ben
-- 

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

2016-02-08 Thread Antonio Perez Barrero 
Avoid looking for debug library unless configuring for MSVC.

Before this change the variable PROTOBUF_LIBRARIES under unix was
'optimized;/usr/lib/libprotobuf.so;debug;/usr/lib/libprotobuf.so'
---
 Modules/FindProtobuf.cmake | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake
index 2f13b09..a07aa83 100644
--- a/Modules/FindProtobuf.cmake
+++ b/Modules/FindProtobuf.cmake
@@ -219,10 +219,12 @@ function(_protobuf_find_libraries name filename)
PATHS 
${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Release)
mark_as_advanced(${name}_LIBRARY)
 
-   find_library(${name}_LIBRARY_DEBUG
-   NAMES ${filename}
-   PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug)
-   mark_as_advanced(${name}_LIBRARY_DEBUG)
+   if(MSVC)
+   find_library(${name}_LIBRARY_DEBUG
+   NAMES ${filename}
+   PATHS 
${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug)
+   mark_as_advanced(${name}_LIBRARY_DEBUG)
+   endif()
 
if(NOT ${name}_LIBRARY_DEBUG)
   # There is no debug library
-- 
1.9.1

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [PATCH] updated a couple of hidden includes made to support CMake's dependency scanning

2016-02-08 Thread Costy Petrisor 
Hello,

I don't know if this patch helps or not, I am not a CMake contributor, but
while checking the code for how a feature is implemented, I found that a
few hidden includes (to support CMake's dependency scanning) were not up to
date.

I did not found a mailing list for kwsys, so I emailed this one instead.

I built this patch in CMake's copy of kwsys, not the standalone kwsys repo.


Hope it helps,
Costy

---

>From 556ee6b4fe653925d5d71e64194002958368d64b Mon Sep 17 00:00:00 2001
From: Costy Petrisor 
Date: Mon, 8 Feb 2016 11:27:53 +
Subject: [PATCH] updated a couple of hidden includes made to support CMake's
 dependency scanning

---
 CommandLineArguments.cxx | 1 +
 ProcessWin32.c   | 2 +-
 SystemInformation.cxx| 1 -
 SystemTools.cxx  | 1 +
 testHashSTL.cxx  | 1 -
 testIOS.cxx  | 6 ++
 6 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/CommandLineArguments.cxx b/CommandLineArguments.cxx
index 3636836..f713294 100644
--- a/CommandLineArguments.cxx
+++ b/CommandLineArguments.cxx
@@ -20,6 +20,7 @@
 #if 0
 # include "CommandLineArguments.hxx.in"
 # include "Configure.hxx.in"
+# include "String.hxx.in"
 #endif

 #include 
diff --git a/ProcessWin32.c b/ProcessWin32.c
index 1f8749f..eabd85f 100644
--- a/ProcessWin32.c
+++ b/ProcessWin32.c
@@ -17,7 +17,7 @@
duplicate the above list of headers.  */
 #if 0
 # include "Process.h.in"
-# include "Encoding_c.h.in"
+# include "Encoding.h.in"
 #endif

 /*
diff --git a/SystemInformation.cxx b/SystemInformation.cxx
index cddcc8d..a33bb6f 100644
--- a/SystemInformation.cxx
+++ b/SystemInformation.cxx
@@ -43,7 +43,6 @@
 #if 0
 # include "SystemInformation.hxx.in"
 # include "Process.h.in"
-# include "Configure.hxx.in"
 #endif

 #include 
diff --git a/SystemTools.cxx b/SystemTools.cxx
index e3428f8..3d8c79a 100644
--- a/SystemTools.cxx
+++ b/SystemTools.cxx
@@ -39,6 +39,7 @@
 // Work-around CMake dependency scanning limitation.  This must
 // duplicate the above list of headers.
 #if 0
+# include "RegularExpression.hxx.in"
 # include "SystemTools.hxx.in"
 # include "Directory.hxx.in"
 # include "FStream.hxx.in"
diff --git a/testHashSTL.cxx b/testHashSTL.cxx
index ab1f83e..ae66ceb 100644
--- a/testHashSTL.cxx
+++ b/testHashSTL.cxx
@@ -18,7 +18,6 @@
 #if 0
 # include "hash_map.hxx.in"
 # include "hash_set.hxx.in"
-# include "hashtable.hxx.in"
 #endif

 #include 
diff --git a/testIOS.cxx b/testIOS.cxx
index 396a09d..5ff7955 100644
--- a/testIOS.cxx
+++ b/testIOS.cxx
@@ -18,6 +18,12 @@
 #include 
 #include  /* strlen */

+// Work-around CMake dependency scanning limitation.  This must
+// duplicate the above list of headers.
+#if 0
+# include "Configure.hxx.in"
+#endif
+
 int testIOS(int, char*[])
 {
   std::ostringstream ostr;
-- 
2.7.0.windows.1
-- 

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] Help: Fix command specification for cmake_minimum_required

2016-02-08 Thread Horst Kronstorfer 
Implementation indicates that at least two components of VERSION must
be specified (see Source/cmCMakeMinimumRequired.cxx.) Therefore the
minor version is not optional.
---
 Help/command/cmake_minimum_required.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Help/command/cmake_minimum_required.rst 
b/Help/command/cmake_minimum_required.rst
index 8573218..dc65a9e 100644
--- a/Help/command/cmake_minimum_required.rst
+++ b/Help/command/cmake_minimum_required.rst
@@ -5,7 +5,7 @@ Set the minimum required version of cmake for a project.
 
 ::
 
-  cmake_minimum_required(VERSION major[.minor[.patch[.tweak]]]
+  cmake_minimum_required(VERSION major.minor[.patch[.tweak]]
  [FATAL_ERROR])
 
 If the current version of CMake is lower than that required it will
-- 
2.5.0

-- 

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

2016-02-08 Thread Konstantin Podsvirov 
Wonderful project "protobuf" ("protobuf" with a small letter "f") starting with 
version 3.0 (which is around the corner - now beta 2), will be built with CMake 
on Windows, and will contain CONFIG scripts with a description of the exported 
package and an imported goal.

That's the name of the project:

https://github.com/google/protobuf/blob/master/cmake/CMakeLists.txt#L5

All targets will be installed in the standard paths, which optionally can be 
configured to your needs (use the GNUInstallDirs module):

https://github.com/google/protobuf/blob/master/cmake/install.cmake#L10

There is also the option to configure Postfix in a debug configuration 
(protobuf_DEBUG_POSTFIX - default "d"):

https://github.com/google/protobuf/blob/master/cmake/CMakeLists.txt#L26

So for protobuf >= 3.0 on Windows you can use
design:

find_package(protobuf CONFIG)

These new features were created with my participation. I tried to create a 
configuration compatible with the all of us known module. Here is a template 
script compatibility for the module:

https://github.com/google/protobuf/blob/master/cmake/protobuf-module.cmake.in

Unfortunately, for platforms other than Windows, use CMake to build protobuf 
not officially planned, but carried out private studies confirm the fact that 
cmake/CMakeLists workable on other platforms.

Thus the project "protobuf" already cmake/CMakeLists.txt and is open to 
modifications and development for the benefit of the CMake community.

While we will continue to work as follows:

find_package(Protobuf [MODULE])

But over time, I hope to do just so:

find_package(protobuf CONFIG)

All suggestions and comments as always are welcome.

And for publicity :-)

You can try pre-built protobuf me 3.0 for Windows (MSVC2013) from Dad's Project 
(installers "testing"):

http://dad.podsvirov.pro/house/installers

(sorry for possible mistakes in text)

09.02.2016, 00:39, "Brad King" :
> 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
> find in several modules.
>
>> Having the variable PROTOBUF_LIBRARIES 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.
>
> -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

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

2016-02-08 Thread Tim Blechmann 
>> 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 0015960]: cmake-gui crashes when I click configure or generate on GLFW project

2016-02-08 Thread Mantis Bug Tracker 

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15960 
== 
Reported By:Matt Schoen
Assigned To:
== 
Project:CMake
Issue ID:   15960
Category:   CMake
Reproducibility:always
Severity:   crash
Priority:   normal
Status: new
== 
Date Submitted: 2016-02-08 21:45 EST
Last Modified:  2016-02-08 21:45 EST
== 
Summary:cmake-gui crashes when I click configure or generate
on GLFW project
Description: 
I get a bunch of Access Violations if I open up a VS2015 debugger after the
crash.  I'm trying to do the first step of the process after pointing the tool
at the source directory.

Using native compilers.  Current version of GLFW is commit hash is
f51cf8114821b9c25d28b5572469de3c18ef446a

Using cmake 3.5.0-rc1
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-02-08 21:45 Matt SchoenNew 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] [PATCH] FindProtobuf: check version

2016-02-08 Thread Antonio Pérez Barrero 
Hi,

thanks for feedback, I'll rework the patch. I was planning to actually
submit three patches covering the following:

* Version checking
* Interface variables rename, keeping backwards compatibility.
* Fix a bug when setting Protobuf_LIBRARIES on Un*x systems.

So what's the best way to submit them:

* A separate format-patch for each.
* An all together patch.
* Fork github's repo, create a branch and send a link here.

Thanks,
Antonio



El mar., 2 feb. 2016 a las 16:18, Rolf Eike Beer ()
escribió:

> > +
> > +  set(Protobuf_VERSION 0)
>
> Just set it to an empty string.
>
> > +  set(Protobuf_LIB_VERSION "")
> > +  file(STRINGS ${_Protobuf_COMMON_HEADER} _Protobuf_COMMON_H_CONTENTS
> > REGEX "#define GOOGLE_PROTOBUF_VERSION ")
>
> I would replace the spaces with "[ \t]+" so a formatting change will not
> break the extraction, also below.
>
> > +  set(_Protobuf_VERSION_REGEX "([0-9]+)")
>
> No need for that variable, just put it into the matches argument below.
>
> > +  if("${_Protobuf_COMMON_H_CONTENTS}" MATCHES "#define
> > GOOGLE_PROTOBUF_VERSION ${_Protobuf_VERSION_REGEX}")
> > +set(Protobuf_VERSION "${CMAKE_MATCH_1}")
> > +  endif()
> > +  unset(_Protobuf_COMMON_H_CONTENTS)
> > +
> > +  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")
>
> You are not required to export these variables, only if you expect it to
> be useful for something beyond version checking. If anyone needs
> specific version fiddling Protobuf_VERSION can be used.
>
> 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?

2016-02-08 Thread Brad King 
On 02/07/2016 01:54 PM, Michael Jackson wrote:
>> What is the oldest version of OS X that CMake actually runs on?
>> I guess I would support the last version of Xcode that actually
>> ran on that platform. In reality this is probably 10.6.8?
[snip]
On 02/08/2016 10:21 AM, Sean McBride wrote:
> What's the oldest version of Xcode that CMake currently supports?

We still have nightly testing on OS X 10.4 with Xcode 2.5.  It was
in support of the i386/ppc universal release binary but that was
dropped as of CMake 3.4.  Now it is really only "just in case" and
because the machine running the tests has not died yet.  I'm not
opposed to dropping Xcode generator support for it since anyone
with such an old machine can always use the makefile generator.

Sean, it looks like you are still running nightly tests on OS X
10.6 with Xcode 4.2:

  https://open.cdash.org/viewNotes.php?buildid=4226138

and OS X 10.5 with Xcode 3.1:

  https://open.cdash.org/viewNotes.php?buildid=4226202

but perhaps do not need the actual Xcode IDE generator to work.

> Personally, I think supporting Xcode 5.0+ would be reasonable at this point.
> It was released about 2.5 years ago and can run on OS X 10.8.

Given Apple's encouragement of developers to always update I think
that would be reasonable for the Xcode IDE generator.  Xcode older
than 6 or so will not even run on OS X 10.11.  Let's give this
thread a while to see if anyone else has feedback.

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] [PATCH] updated a couple of hidden includes made to support CMake's dependency scanning

2016-02-08 Thread Brad King 
On 02/08/2016 06:39 AM, Costy Petrisor wrote:
> I did not found a mailing list for kwsys, so I emailed this one instead.

That's fine, thanks.  I applied it for testing in upstream KWSys here:

 http://review.source.kitware.com/20765

After integration there it will be updated in CMake.

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

2016-02-08 Thread Sean McBride 
On Sat, 6 Feb 2016 11:49:07 +0100, Gregor Jasny via cmake-developers said:

>I'd like to get your feedback on deprecating or dropping support for
>older Xcode versions. During changes on the Xcode generator it gets
>harder and harder to test against old and very old Xcode versions like 3
>and 4.
>
>Are there still users around for these versions of Xcode?

Wikipedia has a nice table of Xcode & OS X:



The problem with supporting only current - 1 as Eric suggests is that also 
excludes older versions of OS X, see the 'min OS X to run' column.

What's the oldest version of Xcode that CMake currently supports?

Personally, I think supporting Xcode 5.0+ would be reasonable at this point.  
It was released about 2.5 years ago and can run on OS X 10.8.

Cheers,

-- 

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


-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] FeatureSummary and Fortran

2016-02-08 Thread Alin Marin Elena 
Hi,

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

-- The Fortran compiler identification is GNU 5.3.1
-- Check for working Fortran compiler: /usr/bin/gfortran
-- Check for working Fortran compiler: /usr/bin/gfortran  -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /usr/bin/gfortran supports Fortran 90
-- Checking whether /usr/bin/gfortran supports Fortran 90 -- yes
-- 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  
-- 
-- The following REQUIRED packages have not been found:

 * MPI

CMake Error at /usr/share/cmake/Modules/FeatureSummary.cmake:556 (message):
  feature_summary() Error: REQUIRED package(s) are missing, aborting CMake
  run.
Call Stack (most recent call first):
  CMakeLists.txt:6 (feature_summary)


-- Configuring incomplete, errors occurred!
See also "/home/alin/playground/cmake/summary/build/CMakeFiles/
CMakeOutput.log".

if I replace Fortran as language with C all is fine as expected. (The same 
happens if I add C to the project)

A simple simple way to reproduce  is the following CMakeLists.txt 

project(testM Fortran)

cmake_minimum_required(VERSION 2.8)
include(FeatureSummary)
find_package(MPI REQUIRED)
feature_summary(WHAT ALL FATAL_ON_MISSING_REQUIRED_PACKAGES)


I see this on linux cmake  3.4.3
I wonder if this is a bug or a feature?


Regards,
Alin


-- 
Without Questions there are no Answers!
__
Dr. Alin Marin ELENA
http://alin.elena.space/
__

signature.asc
Description: This is a digitally signed message part.
-- 

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?

2016-02-08 Thread Brad King 
On 02/07/2016 01:54 PM, Michael Jackson wrote:
>> What is the oldest version of OS X that CMake actually runs on?
>> I guess I would support the last version of Xcode that actually
>> ran on that platform. In reality this is probably 10.6.8?
[snip]
On 02/08/2016 10:21 AM, Sean McBride wrote:
> What's the oldest version of Xcode that CMake currently supports?

We still have nightly testing on OS X 10.4 with Xcode 2.5.  It was
in support of the i386/ppc universal release binary but that was
dropped as of CMake 3.4.  Now it is really only "just in case" and
because the machine running the tests has not died yet.  I'm not
opposed to dropping Xcode generator support for it since anyone
with such an old machine can always use the makefile generator.

Sean, it looks like you are still running nightly tests on OS X
10.6 with Xcode 4.2:

  https://open.cdash.org/viewNotes.php?buildid=4226138

and OS X 10.5 with Xcode 3.1:

  https://open.cdash.org/viewNotes.php?buildid=4226202

but perhaps do not need the actual Xcode IDE generator to work.

> Personally, I think supporting Xcode 5.0+ would be reasonable at this point.
> It was released about 2.5 years ago and can run on OS X 10.8.

Given Apple's encouragement of developers to always update I think
that would be reasonable for the Xcode IDE generator.  Xcode older
than 6 or so will not even run on OS X 10.11.  Let's give this
thread a while to see if anyone else has feedback.

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] [PATCH] Help: fix mistake in cmake-buildsystem(7)

2016-02-08 Thread Brad King 
On 02/07/2016 03:46 PM, Paul Wilkinson wrote:
> The COMPATIBLE_INTERFACE_NUMBER_MAX example now sets
> INTERFACE_CONTAINER_SIZE_REQUIRED on lib1Version2 and lib1Version3 (it
> previously set it on lib1Version2 twice and never on
> lib1Version3. Probably a copy-paste mistake?)

Applied, thanks:

 Help: Fix mistake in cmake-buildsystem(7) example
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d8c90800

-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] Help: Fix command specification for cmake_minimum_required

2016-02-08 Thread Brad King 
On 02/08/2016 06:55 AM, Horst Kronstorfer wrote:
> Implementation indicates that at least two components of VERSION must
> be specified (see Source/cmCMakeMinimumRequired.cxx.) Therefore the
> minor version is not optional.

Applied, thanks:

 Help: Fix command specification for cmake_minimum_required
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a3b91d16

-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] Bug fix: Dylibs inside .framework folders fails in BundleUtilities.cmake.

2016-02-08 Thread Brad King 
On 02/07/2016 11:25 AM, Christian Askeland wrote:
> We could reuse the check from gp_item_default_embedded_path(), instead of
> looking at the result from that function:
> 
>  if((item NOT MATCHES "\\.dylib$") AND (item MATCHES "[^/]+\\.framework/"))
> 
> I haven't tested the line above, but can do so tomorrow and post a new patch,
> if it looks reasonable.

Yes, I think that looks good.

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] CMake 3.5 generation time

2016-02-08 Thread Brad King 
On 02/05/2016 10:16 AM, Brad King wrote:
> It looks like these methods:
> 
>  cmGlobalGenerator::FindTargetImpl
>  cmGlobalGenerator::FindGeneratorTargetImpl
>  cmGlobalGenerator::FindImportedTargetImpl
> 
> are all now using linear searches instead of algorithmically
> efficient data structures like before.

This should fix it:

 Fix internal target lookup performance regression
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6cbf6a51

 Improve internal generator target structure lookup
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9b7d5871

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

2016-02-08 Thread Brad King 
On 02/08/2016 11:47 AM, Antonio Perez Barrero wrote:
> Avoid looking for debug library unless configuring for MSVC.
[snip]
> -   find_library(${name}_LIBRARY_DEBUG
> -   NAMES ${filename}
> -   PATHS 
> ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug)
> -   mark_as_advanced(${name}_LIBRARY_DEBUG)
> +   if(MSVC)
> +   find_library(${name}_LIBRARY_DEBUG
> +   NAMES ${filename}
> +   PATHS 
> ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug)
> +   mark_as_advanced(${name}_LIBRARY_DEBUG)
> +   endif()

It is possible someone builds a debug-named library on unix too.
See `select_library_configurations` and its uses in other find
modules.  That is the conventional way to normalize libraries
across configurations.

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

2016-02-08 Thread Brad King 
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.

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

2016-02-08 Thread Antonio Pérez Barrero 
El lun., 8 feb. 2016 a las 19:28, Brad King ()
escribió:

> On 02/08/2016 11:47 AM, Antonio Perez Barrero wrote:
> > Avoid looking for debug library unless configuring for MSVC.
> [snip]
> > -   find_library(${name}_LIBRARY_DEBUG
> > -   NAMES ${filename}
> > -   PATHS
> ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug)
> > -   mark_as_advanced(${name}_LIBRARY_DEBUG)
> > +   if(MSVC)
> > +   find_library(${name}_LIBRARY_DEBUG
> > +   NAMES ${filename}
> > +   PATHS
> ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug)
> > +   mark_as_advanced(${name}_LIBRARY_DEBUG)
> > +   endif()
>
> It is possible someone builds a debug-named library on unix too.
> See `select_library_configurations` and its uses in other find
> modules.  That is the conventional way to normalize libraries
> across configurations.
>
> 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. Having the PROTOBUF_LIBRARIES variable getting the afore
mentioned value messes up the client code using `find_package(Protobuf)` on
Unix.

I might be wrong, but I think this patch solves one issue, while not
introducing another for debug libraries under Unix, since it wasn't working
either before applying it.

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

2016-02-08 Thread Brad King 
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