Re: [cmake-developers] Ninja and add_subdirectory EXCLUDE_FROM_ALL

On 02/10/2016 10:57 AM, Charles Huet wrote: > When using Unix Makefiles (or MSVC) this causes the subfolder to contain > a new Makefile, allowing me to build easily the whole subdir. > > I cannot find such a facility with Ninja The Makefile generator naturally lays makefiles out with launch

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

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

Re: [cmake-developers] FeatureSummary and Fortran

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:

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

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

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

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

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

On 02/05/2016 09:23 AM, Arnau Quintana wrote: > The problem is that the .pbxproj contains some attributes that seem to be > deprecated. Specifically: > > * “refType" for the “PBXFileReference" isa > * “buildSettings” and “buildStyles” for “PBXProject" isa > > Xcode is nice enough to open

Re: [cmake-developers] CMake 3.5 generation time

On 02/05/2016 09:10 AM, Bartosz Kosiorek wrote: > Finally I was able to finalize git bisect. > Generally without regression time was: real3m44.070s > first bad commit: [0c97d32f7a592a768d614c19b3fd48eab245a2c4] > cmGlobalGenerator: Remove direct storage of target > time increased to real

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

On 02/05/2016 11:35 AM, Arnau Quintana wrote: > I do not know if these are related. Any thoughts? Unfortunately I'm not familiar enough with Xcode to answer. Hopefully someone else can answer. > I am curious about what tests are you running. Could you > please point me to the relevant tests?

Re: [cmake-developers] CMake 3.5 generation time

On 02/04/2016 05:57 PM, Bartosz Kosiorek wrote: > Unfortunately after building locally, the times are totally different (worse). Check CMAKE_BUILD_TYPE in the CMakeCache.txt file of your CMake build and make sure it is "Release". If not, just change it and run "make" again to rebuild. Thanks,

Re: [cmake-developers] CMake 3.5 generation time (was: CMake 3.5.0-rc1 now ready for testing!)

On 02/04/2016 07:09 AM, Bartosz Kosiorek wrote: > There is huge difference in Unix Makefile generation time between > 32 vs 64 bit cmake version: > > 32 bit CMake 3.5.0 generation time: > real5m33.310s > user5m27.268s > sys0m3.540s > > 64 bit CMake 3.5.0 generation time: > real

Re: [cmake-developers] Use unsigned int for cmLinkInterface:: and cmGeneratorTarget::Multiplicity

On 02/03/2016 05:25 PM, Christoph Grüninger wrote: > thanks for your advice. An accoring patch is attached. Thanks, applied: Make cmLinkInterface:: and cmGeneratorTarget::Multiplicity unsigned ints https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=58a4a771 -Brad -- Powered by

Re: [cmake-developers] install(EXCLUDE_FROM_ALL) new feature - request for comment

On 02/04/2016 04:55 AM, Nick Lewis wrote: > I am not familiar with git format-patch After committing locally just run git format-patch HEAD~1.. to construct the patch file. The "~1" specifies the number of commits to go back (via first-parent) and include in the series. > make use of the

Re: [cmake-developers] [partial duplicate of users mailing list] SelectLibraryConfigurations

On 02/03/2016 02:39 PM, Adam Rankin wrote: > So, is it expected that each project in a client's package > will call find_package(xyz)? > I am used to the top level CMakeLists finding all the dependencies, > and then passing the information down into projects. After calling find_package(xyz) the

Re: [cmake-developers] CMake 3.5 generation time

On 02/04/2016 10:29 AM, Bartosz Kosiorek wrote: > I downloaded cmakes from website: > https://cmake.org/download/ > > All generation were done on clean output (deleted all files generated by > cmake) > on the same repository version, in the same directory. > The only difference was cmake version

Re: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles

On 01/29/2016 03:16 PM, Eric Wing wrote: > I need more guidance here. I'm not connecting the dots. > My problem seems to be that the execute_process() in > CMakeDetermineCompilerId.cmake is trying to invoke the command: > 'swift CompilerId/main.swift' [snip] > Looking at the execute_process() that

Re: [cmake-developers] install(EXCLUDE_FROM_ALL) new feature - request for comment

On 02/03/2016 02:31 PM, Brad King wrote: > install: Add EXCLUDE_FROM_ALL option (#14921) > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0b6c4729 > > Tests: Add cases for install() command EXCLUDE_FROM_ALL option > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=670

Re: [cmake-developers] [partial duplicate of users mailing list] SelectLibraryConfigurations

On 02/03/2016 12:47 PM, Adam Rankin wrote: > I am wondering if it should not be populating _LIBRARIES variable > with target names? The _LIBRARIES variables are essentially the legacy interface to modules that provide imported targets. Clients should choose to use the imported targets

Re: [cmake-developers] install(EXCLUDE_FROM_ALL) new feature - request for comment

On 02/01/2016 05:01 AM, Nick Lewis wrote: > https://cmake.org/Bug/view.php?id=14921 Thanks. Actually my request in the issue tracker to post here was meant to have the actual patch file attached so people can see it without digging through the messages and attachments there. Patch revisions or

Re: [cmake-developers] [partial duplicate of users mailing list] SelectLibraryConfigurations

On 02/03/2016 01:03 PM, Adam Rankin wrote: > Is there documentation on best practices for writing findxyz modules? There is a section in the cmake-developer manual: https://cmake.org/cmake/help/v3.5/manual/cmake-developer.7.html#find-modules > How does a client determine the target names that

Re: [cmake-developers] Patch: Remove superfluous semicolon after method

On 01/29/2016 05:43 PM, Christoph Grüninger wrote: > please find attached a minimal patch to fix a GCC 6 pedantic warning > concerning a superfluous semicolon after a method. Applied, thanks: cmAlgorithms.h: remove superfluous semicolon after method

Re: [cmake-developers] [ANNOUNCE] cmake-unit - A new unit testing framework for CMake

On 01/25/2016 11:01 AM, Sam Spilsbury wrote: > Over the last two years I've been working on a new unit testing > framework for CMake. I started this project because I've been writing > some other fairly complex CMake modules and I kept making mistakes > which would take me hours to debug weeks

Re: [cmake-developers] ninja command line options not propagated to ninja invocation for superbuild projects

On 01/28/2016 11:04 AM, Taylor Braun-Jones wrote: > Is this expected behavior, a known bug, or a new bug that I should file? Currently it is expected, but I don't think anyone has thoroughly investigated it or tried to implement it. IIRC it works in Makefile generators only because the make tool

Re: [cmake-developers] Improve FindGit.cmake

On 01/26/2016 04:16 PM, Christoph Grüninger wrote: > Dear CMake devs, > please find attached a patch to slightly improve FindGit.cmake. > > I did test it, but did not understand why GIT_FOUND was set in the first > place. The FPHSA helper sets both for historical reasons. We once had a

Re: [cmake-developers] [CMake] FIND_PROGRAM fails to find file without 'r' bit set

On 01/25/2016 08:27 AM, Ben Boeckel wrote: > It's both :) . FileExists is implemented using access() rather than > something like lstat(), so that would indeed be not a "program" since > the file doesn't "exist". > > It was on my list to fix, but the backwards compatibility argument > (IIRC) made

[cmake-developers] CMake 3.5 feature freeze on 2016-02-01

Hi Folks, The feature freeze in 'master' for CMake 3.5 will be on Feb 1, 2016. In order to get 'master' ready to branch for 3.5, 'next' is now frozen to new features. After 3.5 is branched I'll announce when post-3.5 development in 'next' is open. Meanwhile the following types of changes are

Re: [cmake-developers] CMake daemon for user tools

On 01/20/2016 04:03 PM, Stephen Kelly wrote: > FYI I merged a reduce-allocations branch to next for testing. It came from > Milian here: > > https://github.com/steveire/CMake/pull/1 Very nice! Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake

Re: [cmake-developers] [PATCH] Fix crash in cmExportInstallFileGenerator::FindNamespaces()

On 01/20/2016 09:41 PM, Andrey Pokrovskiy wrote: > Subject: [PATCH] Fix crash in cmExportInstallFileGenerator::FindNamespaces() > > Found it when was building poco library: > https://github.com/pocoproject/poco.git > > Steps to reproduce: > 1. Clone poco > 2. mkdir poco.git/build.make > 3. cd

Re: [cmake-developers] [PATCH V2] FindPNG: Create an imported PNG::PNG target

On 01/21/2016 11:46 AM, Sam Thursfield wrote: > Imported targets are now the recommended way of dealing with external > library dependencies. Thanks, re-applied and merged to 'next' for testing: FindPNG: Create an imported PNG::PNG target (#15911)

Re: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles

On 01/20/2016 08:48 AM, Eric Wing wrote: > I thought maybe setting the internal > CMAKE_${lang}_COMPILER_ID_FLAGS_LIST or > CMAKE_${lang}_COMPILER_ID_FLAGS > to "-version" would fix this. > > But this did nothing. Those are internal details of the CMAKE_DETERMINE_COMPILER_ID function and are not

Re: [cmake-developers] [PATCH] FindPNG: Create an imported PNG::PNG target

On 01/20/2016 11:57 AM, rle...@codelibre.net wrote: >>> + INTERFACE_LIBRARIES "${PNG_LIBRARIES}") > > I would have expected something like > > set_target_properties(PNG::PNG PROPERTIES INTERFACE_LINK_LIBRARIES > ZLIB::ZLIB) Yes. > after all of the "if(EXISTS... add imported link

Re: [cmake-developers] [PATCH] Fix args handling in cmake -E time

On 01/19/2016 09:20 PM, Andrey Pokrovskiy wrote: > Previous implementation had two issues: > * Quotes in arguments where not escaped > * No special treatment for arguments with spaces Thanks for pointing this out. Please try this alternative fix: cmake: Fix `-E time` argument passing to child

Re: [cmake-developers] BUG: Pass --build-config option to ctest for multi-config ExternalProjects

On 01/19/2016 04:39 PM, Taylor Braun-Jones wrote: > However, these patches use the deprecated $ generator > expression instead of $. The rest of ExternalProject.cmake > uses $. Oops, old habit. Revised: ExternalProject: Simplify `cmake --build` configuration passing

Re: [cmake-developers] BUG: Pass --build-config option to ctest for multi-config ExternalProjects

On 01/19/2016 03:54 PM, Taylor Braun-Jones wrote: > For ExternalProjects built with a multi-config generator like "Visual > Studio 12" with `TEST_BEFORE_INSTALL ON` I need this patch: > > https://github.com/Kitware/CMake/compare/master...nocnokneo:patch-1 > > Otherwise, the test step gives the

Re: [cmake-developers] Access output from CheckCXXSourceRuns and CheckCSourceRuns

On 01/19/2016 12:03 PM, Harry Mallon wrote: > I cannot retrieve a version number without linking and interrogating > the library. I could be missing something though. Are you saying that the only API provided by the package in question to get its version number is a runtime call? There is no

Re: [cmake-developers] [PATCH] FindPNG: Create an imported PNG::PNG target

On 01/19/2016 12:43 PM, Sam Thursfield wrote: > Imported targets are now the recommended way of dealing with external > library dependencies. Thanks! Applied with minor doc format fixup and merged to 'next' for testing: FindPNG: Create an imported PNG::PNG target (#15911)

Re: [cmake-developers] [PATCH] FindALSA: Create an imported ALSA:ASound target

On 01/19/2016 11:50 AM, Sam Thursfield wrote: > Imported targets are now the recommended way of dealing with external > library dependencies. Thanks! Adding Roger Leigh to Cc because he has implemented several of these for other modules. > + set(ALSA_LIBRARIES ${ALSA_LIBRARY}) > +

Re: [cmake-developers] [PATCH 0/3] FindwxWidgets improvements

On 09/09/2015 11:01 AM, Brad King wrote: > FindwxWidgets: allow specifying required version > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6089fde5 This introduced a regression reported here: https://cmake.org/Bug/view.php?id=15928 The version extraction from the header is br

Re: [cmake-developers] [PATCH] Now prints warning when --build is not honored

On 01/17/2016 11:35 AM, Ashley Whetter wrote: > As per issue 12641, this patch means that a warning is given when the > "--build" > option is ignored. Thanks for working on this. > I'm not sure if you'd want a different error message here. Ideally all unused arguments would get a warning but

Re: [cmake-developers] [CMAKE][PATCH] fix create_javah on Windows

On 01/19/2016 03:58 AM, CHEVRIER, Marc wrote: > Attached is a patch fixing erroneous handling of CLASSPATH > Update tests accordingly. Thanks, applied: UseJava: Fix create_javah CLASSPATH handling on Windows https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=18c3714f -Brad -- Powered by

Re: [cmake-developers] [PATCH] Added FILTER subcommand to list command

On 01/16/2016 12:10 PM, Ashley Whetter wrote: > In response to issue 0003986, I've implemented a FILTER subcommand to the > "list" > command that filters a list using a regular expression. Nice work. The change looks good except I'd like to bikeshed the name of the option. This is the first

Re: [cmake-developers] [PATCH] Now prints line number of cache parse error

On 01/17/2016 05:09 PM, Ashley Whetter wrote: > To fix issue 11109, this patch implements the printing of the line number of > the > CMakeCache.txt file that causes a parse error when an error occurs. Thanks! Applied with minor fix to the test suite: Print line number of cache parse errors

Re: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles

On 01/18/2016 01:51 PM, Eric Wing wrote: > So the good news is I have a basic add_executable working with Swift > on Linux via the Makefile generator. > > It works with all Swift files, or intermixed C+Swift files. Bridging > header is also supported. Great! > - I’m still copying over some

Re: [cmake-developers] Access output from CheckCXXSourceRuns and CheckCSourceRuns

On 01/18/2016 01:32 PM, Harry Mallon wrote: > https://github.com/Kitware/CMake/pull/209 > This passes through the output of the run (as well as the return value) > so that users can access any output without using try_run. Thanks. The signature of the macro takes a variable for the return value

Re: [cmake-developers] [patch] New find module FindXalanC

On 01/19/2016 11:39 AM, Roger Leigh wrote: > Merged into next from the staging branch "xalanc" for review and > testing. Includes a couple of unit tests to validate. Since it depends > on XercesC, I hope what I've done here for the imported and non-imported > target cases is OK. Thanks.

Re: [cmake-developers] install(EXPORT) with PRIVATE dependency: possible bug

On 01/14/2016 04:12 PM, Tamás Kenéz wrote: > Is this really a bug or did I miss something? It is a bug. Good catch and thanks for the simple example. This should fix it: Fix export of STATIC library PRIVATE dependencies with CMP0022 NEW

Re: [cmake-developers] Git for windows patch

On 01/14/2016 06:48 PM, Shawn Waldon wrote: > patch that tells CMake to look in the default install location for > Git for Windows [2] when asked for git. This is expected to work already as follows. This code:

Re: [cmake-developers] Patch for ExternalProject_Add git clone -o support

On 01/15/2016 12:50 PM, Adam Rankin wrote: > I have attached a patch that provides an implementation of this parameter Thanks! Applied with minor tweaks and a release note: ExternalProject: Add option to set `git clone -o` argument https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=83d63391

Re: [cmake-developers] Git for windows patch

On 01/15/2016 10:25 AM, Brad King wrote: > You'll have to investigate locally to determine why this method is > not working. It looks like a 64-bit CMake binary would not properly include the "Program Files (x86)" directory as a search location due to outdated assumptions. Ple

Re: [cmake-developers] RPATH bug + patch suggestion

On 01/15/2016 09:47 AM, Lior Goldberg wrote: > Specifically, I think that the command "FILE(RPATH_REMOVE ...)" is not subtle > enough, as it removes the compiler's predefined rpath together with the rpath > added by CMake. Good catch, thanks. Patch applied with minor tweaks: install: Do not

Re: [cmake-developers] fixup_bundle with @loader_path

On 01/13/2016 01:38 AM, Simon Wells wrote: > it kept saying that @loader_path/libboost_chrono-mt.dylib was not found It looks like this was now reported here with a patch: https://cmake.org/Bug/view.php?id=15918 We already handle @executable_path, so @loader_path should be handled in a similar

Re: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu

On 01/14/2016 03:38 PM, Alexander Neundorf wrote: > On Thursday, January 14, 2016 21:31:51 Kevin Funk wrote: >> +1 from my side, KDevelop 3 is super ancient (last release around 2008 >> according to the interwebs). Get rid off the generator. > > Brad, what's your opinion on this ? > Removing

Re: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles

On 01/13/2016 06:17 PM, Eric Wing wrote: > Under the hood, I think the LLVM linker can handle all of these > through ld. But I think the thing that is tripping me up is that Swift > seems to need to link against some additional libraries which are not > needed in the pure C case. The swiftc

Re: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu

On 01/13/2016 11:16 AM, Robert Dailey wrote: > Running version 3.2.2 on Ubuntu 15. I run the following command: [snip] > cmake: ../../Source/cmTarget.cxx:722: void > cmTarget::GetSourceFiles(std::vector> &, const string&) const: Assertion `this->GetType() != >

Re: [cmake-developers] Allowing generator expressions in install DIRECTORY

On 01/12/2016 04:34 PM, Yves Frederix wrote: > I am attaching a patch that adds support for generator expressions in > the DIRECTORY arguments of install(DIRECTORY ...). It is my first > contribution Very nice! The impl, docs, and tests all look good. Applied with minor whitespace tweak and a

Re: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles

On 01/08/2016 06:15 PM, Eric Wing wrote: > simple 'swiftc' integration going for ADD_EXECUTABLE, as described in > the original post. Take the generator check out of Modules/CMakeDetermineSwiftCompiler.cmake to get rid of the up-front error. See "Modules/CMakeAddNewLanguage.txt" (many of the

Re: [cmake-developers] Visual Studio 2015 FastLink

On 01/11/2016 03:29 PM, Thomas wrote: > https://cmake.org/Bug/view.php?id=15894 > > I'm writing to request support for the /Debug:FastLink flag which was > introduced in visual studio 2015 (update 1), and the option to generate full > PDB informations. >

Re: [cmake-developers] Add command line options for deprecation message control

On 01/04/2016 06:52 PM, Michael Scott wrote: > To round off the -W options functionality, I've implemented the -Werror > and -Wno-error set of options for the two current types of messages, dev > and deprecated. This includes updating the QT GUI to include new options > for controlling this

Re: [cmake-developers] FindwxWidgets.cmake

On 01/11/2016 01:18 PM, Simon Wells wrote: > The following code is line 191-201, I have tested without this being set > on OSX 10.11 using system clang and both self-built and brew installed > wxwidgets with no problems, Whether its still an issue using gcc on osx > or some other configuration i

Re: [cmake-developers] CMake alternative language

Hi Folks, I'm replying directly to my previous post in this thread in order to consolidate responses to related discussion raised in others' responses to it: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15383

Re: [cmake-developers] VS_GLOBAL_ properties in VS 2010+ (was: patch building and testing)

On 01/08/2016 05:56 PM, Mike Fitzgerald wrote: > I've got the attached, which gives me the results I'd expect Great, thanks. I've applied this and merged to 'next' for testing: VS: Implement VS_GLOBAL_* target properties in VS 2010+ (#13666)

Re: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles

On 12/24/2015 06:13 AM, Eric Wing wrote: > Now that Swift is officially open source and already available for > Linux, I started looking at the build process on Linux which I hope we > can figure out how to incorporate into the CMake Makefile generator. Thanks for digging in to this! > To start

Re: [cmake-developers] [PATCH] Fix some bugs in CPack's DragNDrop generator's handling of LICENSE files

On 01/02/2016 04:11 PM, Andrey Mishchenko wrote: > There were issues in the special-character-escaping and line-wrapping code > which caused DragNDrop packaging to fail mysteriously at a later step with > parsing errors in the sla.r file generated by the following code. Thanks, applied and merged

Re: [cmake-developers] CMake alternative language (was: Using CMake as a library from Python)

Hi Charles, Thanks for your efforts in exploring this topic. CMake's current language grew incrementally out of something that was not originally intended as a programming language. The cmState refactoring Stephen Kelly has started is a huge step toward enabling alternative languages, but there

Re: [cmake-developers] FindSTLSoft.cmake, Problems?

On 12/28/2015 07:31 AM, mikkoi wrote: > A CMake project depends on the header only library STLSoft > (http://www.stlsoft.org/). > We rely on the developer having STLSoft installed or "installed" > (pointed to by an environment variable) on his system for compilation. Ideally packages should

Re: [cmake-developers] patch building and testing

On 01/07/2016 10:36 PM, Mike Fitzgerald wrote: > I wanted to fix an issue (#13666) Great! > 1.) Cloned the git repo, ran bootstrap and make. > 2.) Wrote some code in cmVisualStudio10TargetGenerator.cxx. > > Running make again didn't seem to recompile anything On what platform did you build?

Re: [cmake-developers] Can't find correct openssl on Windows

On 12/18/2015 07:49 PM, Patrick Spendrin wrote: > I attached a patch both here and at the bug report which fixes this > behaviour for the cost of having an additional and ugly option for the > FindOpenSSL.cmake file. > I don't see a different solution, as the no-MD/MT version of the > library is

Re: [cmake-developers] [PATCH] QtDialog: Allow to set CMAKE_SHARE_DIR

On 12/20/2015 05:07 PM, Niels Ole Salscheider wrote: > This is needed for multiarch layouts where the prefix is /usr/${host} but > where arch-independet files are installed to /usr/share. Thanks. Some of the current install dir options default to `share/...` as seen in

Re: [cmake-developers] [PATCH v2] QtDialog: Allow to set CMAKE_XDGDATA_DIR

On 12/21/2015 10:02 AM, Niels Ole Salscheider wrote: > This is needed for multiarch layouts where the prefix is /usr/${host} but > where arch-independet files (like the XDG specific ones) are installed to > /usr/share. Great, thanks. Applied: QtDialog: Add option to control XDG file install

Re: [cmake-developers] parallel install of different cmake versions

On 12/17/2015 10:05 PM, Orion Poplawski wrote: > I'm not sure this would work. There seems to be many places in the code > (some of which the patch addresses) where it calls executes "cmake" or > "ctest" regardless of the name it was called with. AFAIK those all use an absolute path. We don't

Re: [cmake-developers] [PATCH] FindBoost: Boost 1.60 support

On 12/17/2015 06:05 PM, Roger Leigh wrote: > With the release of Boost 1.60, I've updated FindBoost to work with this > version. > > Pushed to > https://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/boost-1.60 > and merged into next for review. Looks good, thanks! -Brad --

Re: [cmake-developers] [PATCH] CMakeParseArguments: Test suite and native implementation

On 12/14/2015 04:52 PM, Matthias Männich wrote: > This adds a test suite for the CMakeParseArguments module. In addition > the second change implements cmake_parse_arguments(...) as native > command. Thanks! Applied with minor tweaks: CMakeParseArguments: add a RunCMake test suite

Re: [cmake-developers] [PATCH] Get the PYTHON_SITELIB directory in FindPythonLibs

On 12/16/2015 05:04 AM, Andreas Schneider wrote: > similar to what I implemented in FindPerlLibs.cmake some years ago, I've > added > PYTHON_SITELIB to FindPythonLibs. With PYTHON_SITELIB you have the location > where to install the python modules you built with cmake. > > Example: > >

Re: [cmake-developers] Fix get_item_rpaths function: gp_append_unique for each rpath returned by "otool" command

On 12/16/2015 08:22 AM, Emilie wrote: > I attach a patch to fix the get_item_rpaths function Thanks, applied: BundleUtilities: Fix handling of multiple RPATHs from OS X otool https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a479d7a0 -Brad -- Powered by www.kitware.com Please keep

Re: [cmake-developers] [PATCH] Get the PYTHON_SITELIB directory in FindPythonLibs

On 12/17/2015 11:39 AM, Andreas Schneider wrote: > If you look at the code, my changes to the code are inside an already existing > > if (PYTHON_EXECUTABLE) > ... > > So if you don't call find_package(PythonInterp) before > find_package(PythonLibs) it will not get the PATH information for

Re: [cmake-developers] [PATCH] FindOpenGL: Don't add AGL to OPENGL_LIBRARIES on OS X.

On 12/12/2015 02:12 PM, David Gobbi wrote: > CMake had been setting OPENGL_glu_LIBRARY to AGL.framework, even > though AGL is not GLU. AGL is simply the GL component for the > deprecated Carbon framework. GLU is provided by OpenGL.framework. > > A side effect of the old behavior was that if AGL

Re: [cmake-developers] parallel install of different cmake versions

On 12/11/2015 06:42 PM, Orion Poplawski wrote: > For Fedora EPEL we often end up packaging newer versions of cmake as cmakeXY > (e.g. cmake34) that can be installed in parallel with the system cmake. This > is a fairly invasive process. I'm attaching the current patch I'm working on > for this.

Re: [cmake-developers] [CMake][PATCH] Fix support of policy 0065 on AIX

On 12/11/2015 05:14 AM, CHEVRIER, Marc wrote: > Attached is a patch to handle correctly policy 0065 Thanks. I found that the same problem exists on HP-UX so I squashed in some changes for that too and applied: AIX,HP-UX: Fix RPATH handling when CMP0065 is set to NEW

Re: [cmake-developers] Clarify on the ways to contribute

On 12/11/2015 04:33 AM, Sebastian Schuberth wrote: > while [1] clearly says that "The preferred entry point for new > contributors is the mailing list", obviously also PRs at GitHub are > merged [2]. Also, internally Kitware seems to use Gerrit [3], which > for me would be the preferred place to

Re: [cmake-developers] [Apple/iOS/OS X] Create subdirectories in Resource directory for Frameworks and Application bundle.

On 12/10/2015 09:52 AM, Bartosz Kosiorek wrote: > How it is officialy supported to tell CMake to create subdirectories > inside "Resources" directory? I'm not particularly familiar with this infrastructure myself, but I do not know of any way to define such a layout now. A new interface may have

Re: [cmake-developers] [PATCH] Imported targets for FindGTest

On 12/10/2015 07:22 PM, rle...@codelibre.net wrote: >> - Add unit test to test imported targets and existing variables > > I should mention that to run the unit test, you must define the GTEST_ROOT > environment variable to point to the gtest build, due to gtest being > annoyingly crippled to be

Re: [cmake-developers] [PATCH] Add Clang support to FindOpenMP

On 12/10/2015 10:49 AM, Chris Pavlina wrote: > Attached is a patch to add the correct option for building OpenMP > code using Clang. Thanks, applied: FindOpenMP: Add Clang support https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1549927d -Brad -- Powered by www.kitware.com Please keep

Re: [cmake-developers] set(CACHE) and the local scope

On 12/10/2015 03:20 PM, Alexander Neundorf wrote: >> set(var ON) >> option(var "description" OFF) >> message("var: ${var}") > > I.e. on the first run it would be OFF (since that's the default value > of the option), and all later runs it would have the value which is in the > cache. This is

Re: [cmake-developers] [PATCH] Support multiple directories by "cmake -E make_directory" command

On 12/09/2015 03:01 PM, Bartosz Kosiorek wrote: > support for multiple directories for make_directory command. Thanks. Applied with minor documentation tweak: cmake: Teach -E make_directory to support multiple input directories https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7984ac5e

Re: [cmake-developers] [CMake][PATCH] AIX RPATH handling

On 12/10/2015 04:03 AM, CHEVRIER, Marc wrote: > I identify the root of the problem: if I specify version 3.4 in > cmake_minimum_required, generated link command (stored in file link.txt) > for an executable does not contains value specified in variable > CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS.

Re: [cmake-developers] set(CACHE) and the local scope

On 12/09/2015 05:35 PM, Ben Boeckel wrote: > So some behavior I was unaware of until today came up: > > set(var ON) > option(var "description" OFF) > message("var: ${var}") > > outputs "OFF" for the first configure and "ON" for subsequent > configures. This is because set(var CACHE)

Re: [cmake-developers] [CMake][PATCH] AIX RPATH handling

On 12/09/2015 09:09 AM, CHEVRIER, Marc wrote: > You are right. I missed this capability. > My first idea was to apply to exec the same approach as for shared lib but I > didn’t found appropriate variable: something like > CMAKE_EXE_CREATE__FLAGS > Or may be CMAKE_EXE_LINKER_FLAGS_INIT can be

Re: [cmake-developers] [CMake][PATCH] AIX RPATH handling

On 12/09/2015 08:02 AM, CHEVRIER, Marc wrote: > Attached is a patch for AIX enabling correct generation of executables > regarding runtime path handling (currently, build paths could be stored > as part of installed executables): option -bnoipath is required for > executables link command

Re: [cmake-developers] Add command line options for deprecation message control

On 12/07/2015 01:51 PM, Michael Scott wrote: >> I noticed one glitch. I built against Qt 5.5.1 on Linux and the >> option dialog seems to truncate the labels. > I think I've fixed it, by using vertical layouts rather than form > layouts and setting the size policy to expanding for the widgets,

Re: [cmake-developers] Keil Armcc support

On 12/09/2015 06:25 AM, yann suisini wrote: > Is theresomme support planned in a near future for the > Keil / Armcc toolchain ? This was contributed recently: Add support for the ARM Compiler (arm.com) https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=035a658f

Re: [cmake-developers] [PATCH] Add support for multiple parameters in cmake -E copy_directory command

On 12/06/2015 02:40 PM, Bartosz Kosiorek wrote: > added support for multiple source directories into copy_directory Thanks. Applied with minor tweaks: cmake: Refine -E chdir documentation https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0903812b cmake: Refine -E copy_if_different

Re: [cmake-developers] [PATCH] FindTIFF: Add imported targets

On 12/03/2015 07:11 PM, Roger Leigh wrote: > I hope this is now staged correctly for review. I've pushed a > tiff-imported-target topic branch and merged into next: Yes, thanks. I've just updated a nightly build client to enable the test for this. -Brad -- Powered by www.kitware.com

<    4   5   6   7   8   9   10   11   12   13   >