Re: [cmake-developers] kwsysProcess threadsafety

Cool. I'd like to have parallel automoc and uic. How about this 4th option? Don't use threads. A single thread is able to spawn multiple processes, and wait on multiple processes, and react when 1 or more processes change state. I'm probably not familiar enough with kwsysProcess to know if

Re: [cmake-developers] CMP0071

- On Sep 26, 2017, at 9:07 AM, Sebastian Holtermann sebl...@xwmw.org wrote: >> I updated and I'm getting this: >> >> CMake Warning (dev) in claro/navigation5/CMakeLists.txt: >> Policy CMP0071 is not set: Let AUTOMOC and AUTOUIC process GENERATED files. >> Run "cmake --help-policy CMP0071"

Re: [cmake-developers] CMP0071

- On Sep 26, 2017, at 9:31 AM, Sebastian Holtermann sebl...@xwmw.org wrote: > On Dienstag, 26. September 2017 09:25:36 CEST clin...@elemtech.com wrote: >> - On Sep 26, 2017, at 9:07 AM, Sebastian Holtermann sebl...@xwmw.org > wrote: >> >> I updated and I'm getting this: >> >> >> >> CMake

Re: [cmake-developers] CMP0071

- On Sep 26, 2017, at 9:07 AM, Sebastian Holtermann sebl...@xwmw.org wrote: >> I updated and I'm getting this: >> >> CMake Warning (dev) in claro/navigation5/CMakeLists.txt: >> Policy CMP0071 is not set: Let AUTOMOC and AUTOUIC process GENERATED files. >> Run "cmake --help-policy CMP0071"

[cmake-developers] CMP0071

I updated and I'm getting this: CMake Warning (dev) in claro/navigation5/CMakeLists.txt: Policy CMP0071 is not set: Let AUTOMOC and AUTOUIC process GENERATED files. Run "cmake --help-policy CMP0071" for policy details. Use the cmake_policy command to set the policy and suppress this warning.

Re: [cmake-developers] CPackProductbuild Scripts

- On Dec 12, 2016, at 9:51 AM, Harry Mallon ha...@codexdigital.com wrote: > Hello, > > I am messing around with the CPackProductbuild stuff to try to port over what > we > had before. Currently it support undocumented options > "CPACK_PREFLIGHT_SCRIPT", "CPACK_POSTFLIGHT_SCRIPT", >

[cmake-developers] possible fix to include in release

Hi, If there is a CMake 3.6.3, I'd like to request the inclusion of https://cmake.org/gitweb?p=cmake.git;a=commit;h=48624b3c Some Linux distros are now shipping cmake-gui on top of Qt5, and the reported QFileDialog problem is present. See also

Re: [cmake-developers] [PATCH v3 5/7] For consoles output on Windows use our own std::streambuf

From what I remember, WriteConsoleW doesn't support redirection to a file or pipe.  I don't see an alternative in the patch for the case where stdout is not attached to the console. Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at:

Re: [cmake-developers] [PATCH] Improve encoding handling on Windows

- On Jun 30, 2016, at 8:18 PM, Dāvis Mosāns davis...@gmail.com wrote: > On Windows getenv uses ANSI codepage so it needs to be encoded to > internally used encoding (eg. UTF-8). Here we use _wgetenv instead > and encode that. > > Also typically Windows applications (eg. MSVC compiler) use

Re: [cmake-developers] [PATCH] Improve encoding handling on Windows

- On Jul 1, 2016, at 8:41 AM, Mike Gelfand mike...@mikedld.com wrote: > On 07/01/2016 05:12 PM, Ben Boeckel wrote: >> On Fri, Jul 01, 2016 at 16:44:32 +0300, Dāvis Mosāns wrote: >>> 2. change GetEnv to return std::unique_ptr which will be >>> automatically deleted once out of scope and we

Re: [cmake-developers] Questions about coding conventions

- On Jun 14, 2016, at 8:09 AM, Daniel Pfeifer dan...@pfeifer-mail.de wrote: > On Tue, Jun 14, 2016 at 3:14 PM, Brad King wrote: >> On 06/13/2016 10:16 AM, Brad King wrote: Can't `std::ifstream` and `std::ofstream` be used directly? It seams that kwsys does

Re: [cmake-developers] Productbuild CPack generator

On Jun 6, 2016 7:28 AM, Brad King <brad.k...@kitware.com> wrote: > > On 06/02/2016 12:03 PM, clin...@elemtech.com wrote: > > I have submitted a productbuild generator this morning. > > Clinton, I see you followed up with some fixups to the topic and have > now squas

Re: [cmake-developers] Productbuild CPack generator

Hi Harry, I have submitted a productbuild generator this morning. https://cmake.org/gitweb?p=cmake.git;a=commit;h=b746bd5c Its capabilities should be about equal to the PackageMaker generator. The code for distribution.xml is shared between PackageMaker and productbuild. The

Re: [cmake-developers] CMake 3.5.2 conflates OSX SDK version with target deployment

- On May 25, 2016, at 12:38 PM, Brad King brad.k...@kitware.com wrote: > On 05/25/2016 02:31 PM, Sean McBride wrote: >> CMake should probably default to the newest SDK (which is what Xcode does). >> I don't see a reason to default to an SDK "matching" the deployment target, >> in fact it's

Re: [cmake-developers] fixup_bundle with @loader_path

- On Jan 14, 2016, at 6:48 AM, Brad King brad.k...@kitware.com wrote: > 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: > >

Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle.

; directory > For iOS it will create "flat" directory structure. > > I could provide patch to fix that issue, if you agree with that. > What do you think about that? > Do you think the same should be applied to "Headers"? > > I think the abstraction seems

Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle.

On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote: > Thanks Clint > > Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly with RESOURCE > property. For every resource which is marked as RESOURCE, will be placed in > root "Resources" directory. > > The CMake code below

Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle.

, if you agree with that. > What do you think about that? > Do you think the same should be applied to "Headers"? I think the abstraction seems reasonable, as well as what you are proposing. However, I'm not an Apple guru. I wonder if there are other Apple experts that can w

Re: [cmake-developers] [PATCH] Qt4Macros generate resources with same file name

On Tuesday, November 24, 2015 11:01:27 AM Joseph Shen wrote: > Dear CMake developers: > > Please view attached small patch that try to fix Qt4Macros generate > resources with same file name error. > > Right now, in the CMake main branch, using cmake with Qt4 library > add resources project can

Re: [cmake-developers] CPack/NSIS is broken after extended length paths fix

On Monday, September 21, 2015 12:28:37 PM Dmitry Kochkin wrote: > Hi Clint, > > >>Actually it's even worse because in current master HEAD I can see that > >>INST_DIR is empty in generated project: !define INST_DIR "" > >>(not sure if that's caused by your change) > > > >Interesting... Do you

Re: [cmake-developers] CPack/NSIS is broken after extended length paths fix

- On Sep 18, 2015, at 6:07 AM, Dmitry Kochkin <co...@mail.ru> wrote: > Hi Clinton, > I was looking into an issue that we have in CMake on Windows with extended > paths > and later on realized that you've fixed it. > However I've realized that you fixed it only in cmSys

Re: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks

On Wednesday, September 16, 2015 11:04:23 PM David Gobbi wrote: > On Wed, Sep 16, 2015 at 9:41 AM, Brad King wrote: > > On 09/16/2015 11:39 AM, Brad King wrote: > > > On 09/16/2015 10:00 AM, David Gobbi wrote: > > >> this new patch only changes the search for the include

Re: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks

On Thursday, September 17, 2015 12:54:26 PM Brad King wrote: > On 09/17/2015 12:42 PM, David Gobbi wrote: > > Okay, Clinton. Now you've made me paranoid that I should be prepending > > the value of CMAKE_OSX_SYSROOT before the prefix if it isn't already > > part of the

Re: [cmake-developers] "Inconsistent sizeofcmds" on Mac

On Thursday, September 17, 2015 11:18:06 PM Mike Gelfand wrote: > Hello everyone, > > I’m using cmake 3.3.1 on Mac 10.10.4. I’m building an executable target on > Mac with the following settings: > > CMAKE_OSX_ARCHITECTURES = i386;x86_64 > CMAKE_OSX_DEPLOYMENT_TARGET = 10.5 >

Re: [cmake-developers] Modules/GetPrequisites.cmake issues

On Monday, August 03, 2015 10:22:18 AM Brad King wrote: On 07/30/2015 10:56 AM, Brad King wrote: Thanks! Applied: Those patches exposed a bug in FindMPI, so I fixed that and rebased the other changes on it: FindMPI: Drop unnecessary and incorrect use of GetPrerequisites

Re: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation

On Thursday, July 30, 2015 10:56:02 AM Brad King wrote: On 07/30/2015 09:29 AM, Pascal Bach wrote: CMAKE_FIND_ROOT_PATH_MODE would then need to be extended to support something like NATIVE and TARGET that one could use to choose where to look for files. This way every find_* call could

Re: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation

On Wednesday, July 29, 2015 04:59:57 PM Pascal Bach wrote: Hi Clint Am 29.07.2015 um 16:47 schrieb Clinton Stimpson: On Wednesday, July 29, 2015 04:05:41 PM Pascal Bach wrote: Hi Clint Am 29.07.2015 um 15:45 schrieb Clinton Stimpson: Hi Pascal, Thanks for the patches. Can

Re: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation

Hi Pascal, Thanks for the patches. Can you share with us why setting CMAKE_FIND_ROOT_PATH does not work, or how this new method compares? For example, in the toolchain file: SET(CMAKE_FIND_ROOT_PATH /path/to/Qt ...) Clint On Wednesday, July 29, 2015 02:32:48 PM Pascal Bach wrote: ---

Re: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation

On Wednesday, July 29, 2015 04:05:41 PM Pascal Bach wrote: Hi Clint Am 29.07.2015 um 15:45 schrieb Clinton Stimpson: Hi Pascal, Thanks for the patches. Can you share with us why setting CMAKE_FIND_ROOT_PATH does not work, or how this new method compares? For example

Re: [cmake-developers] Support of codesign

GMT+01:00 Clinton Stimpson clin...@elemtech.com: On Friday, February 20, 2015 12:07:55 PM A. Klitzing wrote: Hi Clint, I have another patch to tweak the error output a little bit. If codesign fails it won't be possible to get the error message of codesign itself

Re: [cmake-developers] Support of codesign

On Friday, February 20, 2015 12:07:55 PM A. Klitzing wrote: Hi Clint, I have another patch to tweak the error output a little bit. If codesign fails it won't be possible to get the error message of codesign itself. That is a little bit confusing because it just fails without an

Re: [cmake-developers] [PATCH] User may now specify toolset through CMake GUI

On Monday, February 16, 2015 11:35:47 AM Brad King wrote: On 02/15/2015 03:27 PM, rcdailey.li...@gmail.com wrote: From: Robert Dailey rcdai...@gmail.com The -T parameter to CMake may now be specified through QtDialog (cmake-gui) via a new text field in the first-time configure wizard

Re: [cmake-developers] Patch for some GUI Mac fixes

On Monday, January 26, 2015 08:01:31 AM Kevin Wojniak wrote: These 3 patches fix the Install menu not showing for Qt5 builds, the Install buttons not behaving like the other (standard) buttons, and fixes the search field not being shown on OS X when the window is at minimum size. Thanks for

Re: [cmake-developers] New RelWithDebInfo flags?

- Original Message - Hi, I just discovered today that it looks like GCC 4.8 shipped with a new optimization level: -Og Optimize debugging experience. -Og enables optimizations that do not interfere with debugging. It should be the optimization level of choice

[cmake-developers] CMake 3.1 regression with incremental builds ?

Using the netcdf project ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-4.3.2.tar.gz I see a problem with incremental builds doing a relink of libraries. Within my project, this leads to unnecessarily relinking of many executables every time I run cmake. For example: tar zxf

Re: [cmake-developers] CMake 3.1 regression with incremental builds ?

I've put in a fix for this. 580b668d genex: Preserve order while evaluating TARGET_OBJECTS Can we put this in RC 2? Clint - Original Message - Using the netcdf project ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-4.3.2.tar.gz I see a problem with incremental builds doing a relink

Re: [cmake-developers] Support of codesign

Klitzing Clinton Stimpson clin...@elemtech.com schrieb am Mon Oct 27 2014 at 17:42:50: Hi André, I can help you get this patch into the git repo. But before doing that, Brad requested one more change. Can you please rename 3 of the CMake variables

Re: [cmake-developers] Support of codesign

On Thursday, October 23, 2014 11:13:15 AM Brad King wrote: On 10/21/2014 11:44 AM, Clinton Stimpson wrote: Because the design of this Bundle generator is not consistent with the rest of the CPack generators, you don't have this same chance, and the only way to do customization is to keep

Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

On Tuesday, October 21, 2014 08:22:24 AM Clinton Stimpson wrote: On Tuesday, October 21, 2014 03:59:19 PM Adam Strzelecki wrote: Regardless of where the bug lies, your changes took a packaging case that worked and made it not work. That is a regression. I am sorry, but 55707fd5

Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

On Tuesday, October 21, 2014 03:59:19 PM Adam Strzelecki wrote: Regardless of where the bug lies, your changes took a packaging case that worked and made it not work. That is a regression. I am sorry, but 55707fd5 in fact does it CORRECT WAY as it is expressed in:

Re: [cmake-developers] Support of codesign

/2014 02:00 PM, Clinton Stimpson wrote: I think application signing is generally not a CPack thing, but there probably isn't much of a choice if the Bundle generator is used. Well, it isn't possible to sign that bundle without it. There must be a step between bundle and dmg. Maybe cmake

Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

- Original Message - On 10/08/2014 11:05 AM, clin...@elemtech.com wrote: I pushed more fixes for this. Instead of requiring 10.6, I took the other path of warning when rpaths need changed at install time and skip it. This should also fix the CMP0042 test which started failing.

Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

- Original Message - Adam, On 10/08/2014 12:17 PM, Clinton Stimpson wrote: Yeah. I'm curious if changes to BundleUtilities.cmake in fix-OSX-bundle- rpaths-and-Qt5 will gracefully handle the BundleUtilities test case with @rpath on OS X 10.5. Perhaps it'll recognize

Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

On Thursday, October 09, 2014 10:27:32 AM Brad King wrote: On 10/09/2014 10:16 AM, clin...@elemtech.com wrote: When I do the same message(), I don't see deletion of rpaths which do not exist. I see them for libshared and libshared2 which have SKIP_BUILD_RPATH. But, I'm wondering if

Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

but there could still be people just building for their own host as the only computer they have. The fact that our dashboard reported this problem means we are testing that case. Clinton, I don't have a 10.5 machine anymore and the test is failing on yours. Please take whatever action you feel

Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

On Wednesday, October 08, 2014 11:17:03 AM Brad King wrote: On 10/08/2014 11:05 AM, clin...@elemtech.com wrote: I pushed more fixes for this. Instead of requiring 10.6, I took the other path of warning when rpaths need changed at install time and skip it. This should also fix the CMP0042

Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

by tests. Clinton, what do you think of changing the Darwin.cmake test for enabling @rpath support to require OS X 10.6 instead of 10.5? Otherwise we may be leaking build tree RPATH entries into installed files on 10.5. Sure, I think it would be good to require 10.6. We also have uses

Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

for their own host as the only computer they have. The fact that our dashboard reported this problem means we are testing that case. Clinton, I don't have a 10.5 machine anymore and the test is failing on yours. Please take whatever action you feel is appropriate to resolve the test failure

Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

topic ready to be merged to 'next' for testing? Clinton, have your comments been addressed? Thanks, -Brad My concerns of breaking backward compatibility were already addressed. However, I do wish there is a test for this. Although the commits target OS X, I would like to see some proof

Re: [cmake-developers] Support of codesign

- Original Message - It should not be an error for 'codesign' to not be available in the PATH. The user may have set CPACK_COMMAND_CODESIGN to some other location. The error should only occur if no value for CPACK_COMMAND_CODESIGN is available when the tool is actually

Re: [cmake-developers] Support of codesign

On Monday, September 29, 2014 01:23:04 PM Chuck Atkins wrote: Maybe it shouldn't even be a CPack thing. Maybe it should be an install time step so that all CPack generators will contains signed binaries if codesign is used... I know this is a bit after the fact and I'm jumping in here

Re: [cmake-developers] Support of codesign

I would suggest the SignPackage function be moved from cmCPackDragNDropGenerator to cmCPackBundleGenerator because its implementation is only usable by cmCPackBundleGenerator. It uses CPACK_BUNDLE_NAME which is only valid in the context of cmCPackBundleGenerator. Clint - Original

Re: [cmake-developers] [PATCH 3/6] Resolve replace @rpath placeholders

On Thursday, September 18, 2014 06:15:51 PM Adam Strzelecki wrote: FYI I pushed stage/fix-OSX-bundle-rpaths-and-Qt5 topic for final review. Regards, Does the functionality you add allow us to modify CMake/Tests/BundleUtilities/CMakeLists.txt such that the last part in the tests where @rpath

Re: [cmake-developers] [PATCH 3/6] Resolve replace @rpath placeholders

On Wednesday, September 17, 2014 01:13:45 AM Adam Strzelecki wrote: What is the new optional parameter to gp_file_type() used for? My intention was to pass exepath rather than take it from the path of original_file. But this is in fact not necessary. I don't see any code in your branch

Re: [cmake-developers] [PATCH 3/6] Resolve replace @rpath placeholders

on:) -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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

Re: [cmake-developers] [PATCH 3/6] Resolve replace @rpath placeholders

of /path/to/ No? These functions are called by other codes and we can't just change the meaning of the arguments. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Please keep messages on-topic and check

Re: [cmake-developers] [PATCH 3/6] Resolve replace @rpath placeholders

Yes, it would be easier to review on stage or on github. Thanks. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki

Re: [cmake-developers] [PATCH 3/6] Resolve replace @rpath placeholders

parameter to gp_file_type() used for? I don't see any code in your branch calling that function with the new parameter. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Please keep messages on-topic and check

Re: [cmake-developers] [PATCH 3/6] Resolve replace @rpath placeholders

I think it would be nice to move get_item_rpaths() from BundleUtilities.cmake to gp_item_get_rpaths() in GetPrerequisites.cmake. And how does your patch or patch set handle @loader_path being used in the rpath? Also, I think the function signature should include the rpath vs runpath

Re: [cmake-developers] [ANNOUNCE] CMake 3.0.0 Released.

- Original Message - On 11.06.2014 10:52, Kornel Benko wrote: Am Dienstag, 10. Juni 2014 um 17:14:31, schrieb Robert Maynard robert.mayn...@kitware.com On behalf of myself, Ken, Bill, Brad, David, Alex, Eike, Steve, Zach, Ben, Peter, Nils, and the rest of the CMake team from all

Re: [cmake-developers] Please review FindQt_versioned_tools

://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2251970c (qmake-qt4 qmake) Then the order was reversed without much detail in the commit: ENH: -apply the patches by Clinton Stimpson, 2006-04-27 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f59ad1aa (qmake qmake-qt4) The commit message

[cmake-developers] sporadic build failures with ninja

I'm seeing some build problems show up on cdash from some of my builds that use ninja. The error that shows up on cdash is: ninja: error: GetFileAttributesEx(c:\Program Files (x86)\Mcl : Command line warning D9025 : overriding ): The filename, directory name, or volume label syntax is

Re: [cmake-developers] Please review FindQt_versioned_tools

On Tuesday, May 20, 2014 05:53:16 PM Rolf Eike Beer wrote: Clinton, Stephen, inspired by what OpenBSD currently does downstream I did a patch that always searches for the plain executable names (like moc) after all versioned executable names (e.g. moc4) have been tried. Since those tools

Re: [cmake-developers] CMake identifies MacOSX10.7-Xcode43-ub as GNU, but it runs clang.

On Tuesday, April 29, 2014 11:01:06 AM Brad King wrote: On 04/28/2014 01:07 PM, Brad King wrote: It looks like in this case users will have to tell Xcode what tool to use up front using the CMake generator toolset feature (cmake -T). I think this is acceptable because it only affects old

Re: [cmake-developers] Review request: fix-Qt5-windows-build

On Wednesday, March 12, 2014 05:21:30 PM Stephen Kelly wrote: Hi, I didn't follow the encoding work done by Clinton, and in my Qt 5 build with default settings, the new codepage related definition is not set. However, if it is set somehow, then the build would be calling methods which

Re: [cmake-developers] Review request: fix-Qt5-windows-build

On Wednesday, March 12, 2014 05:50:09 PM Stephen Kelly wrote: Clinton Stimpson wrote: I personally would prefer a Qt version check This compiles: diff --git a/Source/QtDialog/CMakeSetup.cxx b/Source/QtDialog/CMakeSetup.cxx index 995929e..d1fbe9f 100644 --- a/Source/QtDialog

Re: [cmake-developers] Question regarding [58e3d49] MSVC: Fix encoding of Visual Studio 10+ project files

On Thursday, March 06, 2014 11:09:24 AM Dominik Bernhardt wrote: Hi, I have a question regarding the change [58e3d49] that changed the encoding of generated visual studio project files from utf-8 to Windows-1252. Although the encoding header in the generated xml file was changed the files

Re: [cmake-developers] WG: [CMake] CMake 2.8.12.201401116 is much slower than 2.8.12.1

On Wednesday, January 29, 2014 02:35:53 PM Dominik Bernhardt wrote: -Urspruengliche Nachricht- Von: Clinton Stimpson [mailto:clin...@elemtech.com] Gesendet: Dienstag, 21. Januar 2014 16:10 An: cmake-developers@cmake.org Cc: Bill Hoffman; Dominik Bernhardt Betreff: Re: [cmake

Re: [cmake-developers] [CMake] CMake 2.8.12.201401116 is much slower than 2.8.12.1

On Thursday, January 16, 2014 08:41:58 AM Clinton Stimpson wrote: On Thursday, January 16, 2014 10:14:32 AM Bill Hoffman wrote: Moving this to cmake-developers list: On 1/16/2014 9:55 AM, Clinton Stimpson wrote: On one of my projects, I see ~3.0 seconds for CMake 2.8.12 and ~3.8

Re: [cmake-developers] [CMake] CMake 2.8.12.201401116 is much slower than 2.8.12.1

On Thursday, January 16, 2014 10:14:32 AM Bill Hoffman wrote: Moving this to cmake-developers list: On 1/16/2014 9:55 AM, Clinton Stimpson wrote: On one of my projects, I see ~3.0 seconds for CMake 2.8.12 and ~3.8 seconds for CMake master. I don't have an idea why, but with my test

Re: [cmake-developers] [CMake] CMake 2.8.12.201401116 is much slower than 2.8.12.1

On Thursday, January 16, 2014 11:49:58 AM Ben Boeckel wrote: On Thu, Jan 16, 2014 at 08:41:58 -0700, Clinton Stimpson wrote: I'm surprised how this small change added a 20% slowdown. -set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS_DEBUG QT_DEBUG) +set_property(DIRECTORY APPEND

Re: [cmake-developers] [CMake 0014692]: UseQt4.cmake does not adhere to policy CMP0043

On Friday, January 10, 2014 11:14:11 AM Brad King wrote: On 01/10/2014 11:10 AM, Clinton Stimpson wrote: Well, I was getting those warnings because I was using UseQt4.cmake. I think I was getting it for every target that inherited settings from UseQt4.cmake. So in my case, it is directly

Re: [cmake-developers] Cmake configure unicode?

If you want cmake to support unicode with configure_file right now, use utf-8, not utf-16. I just tried with a utf-8 file with various non-ascii characters on Windows and configure_file() works for me. From your use of cmd /U, it appears you are attempting to do utf-16 (which is what

Re: [cmake-developers] Possible issue with UseQt4.cmake

- Original Message - I noticed today that the UseQt4 module appends a lot of different data to the COMPILE_DEFINITIONS property via add_definitions but appends only one item to various COMPILE_DEFINITIONS_CONFIG properties. Is this a bug in the UseQt4 module? I don't think that is

[cmake-developers] help with cdash failure

I assume these new failures are mine, but cannot reproduce it. http://open.cdash.org/testDetails.php?test=222455969build=3128109 http://open.cdash.org/testDetails.php?test=222466359build=3128147 I've tried on Windows 7 with MSVC 2012 and 2005, debug and release. Can someone check why the test

Re: [cmake-developers] help with cdash failure

On Friday, December 06, 2013 03:17:44 PM Brad King wrote: On 12/06/2013 01:41 PM, Clinton Stimpson wrote: I assume these new failures are mine, but cannot reproduce it. http://open.cdash.org/testDetails.php?test=222455969build=3128109 http://open.cdash.org/testDetails.php?test

Re: [cmake-developers] Cross compiling toolchain variables

- Original Message - On 10/30/2013 05:27 PM, Stephen Kelly wrote: Brad King wrote: I want to make sure that downstream uses the same GL headers and libraries as the ones used to build Qt itself. The PATHS is populated with information from qmake, and I wanted to prevent cmake

Re: [cmake-developers] CMake 2.8.12 transitive link regression?

2.8.12 to 2.8.12.1. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake

Re: [cmake-developers] CMake 2.8.12 transitive link regression?

On Monday, November 04, 2013 10:40:15 AM Brad King wrote: On 11/04/2013 10:31 AM, Clinton Stimpson wrote: But I see 2 others new problems. Those are features and they work together as intended. 1) cmake_minimum_required(VERSION 2.8) add_library(foo SHARED foo.cpp) add_library(bar

Re: [cmake-developers] CMake 2.8.12 transitive link regression?

On Monday, November 04, 2013 09:16:11 AM Clinton Stimpson wrote: On Monday, November 04, 2013 10:40:15 AM Brad King wrote: On 11/04/2013 10:31 AM, Clinton Stimpson wrote: But I see 2 others new problems. Those are features and they work together as intended. 1

[cmake-developers] CMake unicode support

Hi All, I've started some work towards supporting Unicode in CMake so I could get better support for building/testing our internationalized applications. https://github.com/clintonstimpson/CMake/commit/f08ca2ff65f434b2bc404000765a836880f78f0e It keeps char* / std::string throughout the code

Re: [cmake-developers] [CMake] CMake 2.8.12-rc2 FindHDF5 issues

On Thursday, September 19, 2013 01:47:23 PM Brad King wrote: On 09/17/2013 06:16 PM, Clinton Stimpson wrote: I've narrowed it down to a regression caused by 04d4dc33. The following should fix this: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0f05961f See the commit message

Re: [cmake-developers] [CMake] CMake 2.8.12-rc2 Released

Same here... and this looks like a regression: A simple CMakeLists.txt like this can reproduce it. set(CMAKE_BUILD_TYPE Debug) find_package(HDF5 COMPONENTS C HL REQUIRED) add_executable(foo foo.cpp) target_link_libraries(foo ${HDF5_LIBRARIES}) FindHDF5.cmake misuses CMAKE_BUILD_TYPE and

Re: [cmake-developers] [CMake] CMake 2.8.12-rc2 FindHDF5 issues

On Tuesday, September 17, 2013 04:01:30 PM Orion Poplawski wrote: On 09/16/2013 09:58 PM, clin...@elemtech.com wrote: Same here... and this looks like a regression: A simple CMakeLists.txt like this can reproduce it. set(CMAKE_BUILD_TYPE Debug) find_package(HDF5 COMPONENTS C HL

Re: [cmake-developers] compile-defs-debugging and framework-interface-includes

- Original Message - Hi there, compile-defs-debugging is failing with some Visual Studio generators. I don't have those ides to figure out what is going wrong. My reading of the Preprocessor test indicates that if my new test fails, that one should too, so I don't understand where

Re: [cmake-developers] [CMake 0014274]: QtDialog Compiler Chooser Should Not Resolve Symlinks

- Original Message - Clinton, On 07/06/2013 07:09 AM, Mantis Bug Tracker wrote: http://www.cmake.org/Bug/view.php?id=14274 The qtdialog-symlinks topic on the stage appears to be meant for this but has not been merged to 'next' for testing. Did you mean to? Please merge

Re: [cmake-developers] rpath-on-mac topic

- Original Message - Clinton, On 07/17/2013 01:07 AM, Clinton Stimpson wrote: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=90993b9016abf241cd0a4de71e76eb738202c136 commit 90993b9016abf241cd0a4de71e76eb738202c136 Author: Clinton Stimpson clin...@elemtech.com

Re: [cmake-developers] CMAKE_SYSROOT vs CMAKE_OSX_SYSROOT

- Original Message - On 07/11/2013 10:41 AM, clin...@elemtech.com wrote: They also appear similar to me, so I would start with the assumption that they should be unified. I just dug into this a bit. One difference is that CMAKE_OSX_SYSROOT can be set to a logical SDK name

[cmake-developers] ninja support

Is there someone that can offer some ninja support? There is a regression from a while back exposed by a commit of mine yesterday. http://open.cdash.org/testDetails.php?test=199232514build=2967911 With the framework refactor work, the soname for frameworks were fixed. As a result, code in the

Re: [cmake-developers] ninja support

- Original Message - Is there someone that can offer some ninja support? There is a regression from a while back exposed by a commit of mine yesterday. http://open.cdash.org/testDetails.php?test=199232514build=2967911 With the framework refactor work, the soname for frameworks were

Re: [cmake-developers] CMAKE_SYSROOT vs CMAKE_OSX_SYSROOT

? Clinton, can you comment on this? They do appear to be very similar. Both are about the toolchain's system headers/libs and platform SDK location. I don't really know much more than that. They also appear similar to me, so I would start with the assumption that they should be unified. Clint

Re: [cmake-developers] Deprecating qt4_use_modules and qt4_automoc?

- Original Message - Stephen Kelly steveire@... writes: We could also probably add a runtime warning if enabled. You need to enable deprecation warnings with your compiler, so it would make sense to have to enable them with a cmake script too. CMAKE_ENABLE_DEPRECATION_WARNINGS

Re: [cmake-developers] How should Mac frameworks work?

On Tuesday, July 02, 2013 05:12:00 PM Stephen Kelly wrote: Clinton Stimpson wrote: Yeah, I understand that is the issue. I don't quite get what is new for Qt 5.1. I thought Qt 4.x only installed Qt headers inside the framework too. Perhaps its new from 5.0 to 5.1? Yes. On a Mac

Re: [cmake-developers] How should Mac frameworks work?

on imported frameworks. Take the above paragraph with a grain of salt because I wrote it off the top of my head and haven't had a chance to look at the code. Clinton, you refactored all of the internals for this recently. Can you comment, please? Thanks, -Brad With the refactor

Re: [cmake-developers] How should Mac frameworks work?

On Monday, July 01, 2013 07:36:24 PM Stephen Kelly wrote: Clinton Stimpson wrote: This change hasn't been released yet and will go into CMake 2.8.12. Ah, I see. I was mis-reading my gitk. If Qt were to put multiple versions of libraries into one framework, then I think

Re: [cmake-developers] Review request: qt4-macros-TARGET-arg

. Previously, those macros read the INCLUDE_DIRECTORIES directory property, which is populated by the include_directories() command. So, this patch to the macros makes it possible to not require the use of include_directories() anymore to use the macros. Clinton, could you take a look before I

Re: [cmake-developers] [CMake] BundleUtilities and @rpath

/002572.html So, a question I have for you is how do you think stage/rpath-on-mac could affect your topic? Clint On Thursday, May 16, 2013 07:57:01 PM Jean-Christophe Fillion-Robin wrote: Hi Clinton, This is to create bundle that use @rpath. Particularly useful when you want to support

[cmake-developers] Xcode and dylib versioning

Does anyone know if/how Xcode can handle versioning of dylibs that include symbolic links? When creating versioned shared libraries with Makefiles, I get the symbolic links. But, I don't get that when building with Xcode. I realize CMake generated Xcode projects don't support this, but I'm

Re: [cmake-developers] Need some pointers on learning the code

On Monday, May 13, 2013 02:30:32 PM Brad King wrote: On 05/13/2013 02:07 PM, Robert Dailey wrote: Actually now that I think about this a littler closer, changing the generator expressions may not work for a specific case I'm blocked on. I store my third party library binaries in a debug

Re: [cmake-developers] Need some pointers on learning the code

On Monday, May 13, 2013 12:55:39 PM Clinton Stimpson wrote: On Monday, May 13, 2013 02:30:32 PM Brad King wrote: On 05/13/2013 02:07 PM, Robert Dailey wrote: Actually now that I think about this a littler closer, changing the generator expressions may not work for a specific case I'm

  1   2   >