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

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

Re: [cmake-developers] Drop support for older Xcode versions?

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,

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

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

[cmake-developers] [PATCH] FindProtobuf: fix wrong library list for Unix

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

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

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

[cmake-developers] [PATCH] Help: Fix command specification for cmake_minimum_required

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

Re: [cmake-developers] [PATCH] FindProtobuf: fix wrong library list for Unix

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

Re: [cmake-developers] Drop support for older Xcode versions?

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

[cmake-developers] [CMake 0015960]: cmake-gui crashes when I click configure or generate on GLFW project

The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=15960 == Reported By:Matt Schoen Assigned To:

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

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

Re: [cmake-developers] Drop support for older Xcode versions?

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

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

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!

Re: [cmake-developers] Drop support for older Xcode versions?

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

[cmake-developers] FeatureSummary and Fortran

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:

Re: [cmake-developers] Drop support for older Xcode versions?

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

Re: [cmake-developers] [PATCH] Help: fix mistake in cmake-buildsystem(7)

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:

Re: [cmake-developers] [PATCH] Help: Fix command specification for cmake_minimum_required

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

Re: [cmake-developers] [PATCH] Bug fix: Dylibs inside .framework folders fails in BundleUtilities.cmake.

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

Re: [cmake-developers] CMake 3.5 generation time

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

Re: [cmake-developers] [PATCH] FindProtobuf: fix wrong library list for Unix

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

Re: [cmake-developers] [PATCH] FindProtobuf: fix wrong library list for Unix

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

Re: [cmake-developers] [PATCH] FindProtobuf: fix wrong library list for Unix

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

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.