Re: [CMake] Best way to handle application data path for local run vs. installation

On Tuesday, December 01, 2015 07:17:35 Ruslan Baratov wrote: > On 01-Dec-15 03:51, Alexander Neundorf wrote: > > On Monday, November 30, 2015 16:13:03 Ruslan Baratov via CMake wrote: > > > On 30-Nov-15 09:10, Dmitry Marakasov wrote: > > > > Hi! > > > > ... > > > > > > The best solution would be

[cmake-developers] [CMake 0015869]: g++ from MinGw check already failes

The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=15869 == Reported By:Igor Mironchik Assigned To:

Re: [cmake-developers] Add CXX_STANDARD support for Intel C++ compilers

On 12/01/2015 12:47 PM, Levi Morrison wrote: > I am having trouble reproducing this failure. When I do an > unrestricted ctest (test everything) it will fail, but if I do > something like `ctest -VV -R WriteCompilerDetectionHeader` it will > pass. Any ideas? Try ensuring that it is a fresh run of

Re: [cmake-developers] Add CXX_STANDARD support for Intel C++ compilers

On Tue, Dec 1, 2015 at 7:11 AM, Brad King wrote: > On 11/30/2015 02:13 PM, Levi Morrison wrote: >> Hmm. > > Thanks. I applied it yesterday and merged to 'next' for testing: > > Features: Record standards and features for Intel C++ on UNIX >

[Cmake-commits] CMake branch, master, updated. v3.4.0-626-gbb5fccd

_VERSION_MINOR 4) -set(CMake_VERSION_PATCH 20151201) +set(CMake_VERSION_PATCH 20151202) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/

Re: [CMake] Best way to handle application data path for local run vs. installation

On 02-Dec-15 05:13, Alexander Neundorf wrote: On Tuesday, December 01, 2015 07:17:35 Ruslan Baratov wrote: > On 01-Dec-15 03:51, Alexander Neundorf wrote: > > On Monday, November 30, 2015 16:13:03 Ruslan Baratov via CMake wrote: > > > On 30-Nov-15 09:10, Dmitry Marakasov wrote: > > > > Hi!

Re: [CMake] Best way to handle application data path for local run vs. installation

On 02-Dec-15 12:27, Ruslan Baratov via CMake wrote: If you pass "/usr/local" output will be (nice): -- /usr/local -- If you pass "/home/username", output will be (nice): /home/username If you pass

Re: [cmake-developers] [CMake] Obtaining header file dependencies of a source file manually

>> There is an alternative which I suggested in the post. Have CMake >> determine the dependencies of the files passed to ``IMPLICIT_DEPENDS`` >> at configure time and spit that into the build files of the generator >> (that would work for any generator). Then have any changes made to the >> files

Re: [CMake] [cmake-developers] Obtaining header file dependencies of a source file manually

>> There is an alternative which I suggested in the post. Have CMake >> determine the dependencies of the files passed to ``IMPLICIT_DEPENDS`` >> at configure time and spit that into the build files of the generator >> (that would work for any generator). Then have any changes made to the >> files

Re: [CMake] [cmake-developers] Obtaining header file dependencies of a source file manually

> I fail to see why that should not work. Producing LLVM bitcode from > C++ with Clang is just adding -emit-llvm flag, right? So, why can't > the SuperBuild configure the child build to use Clang and this flag? > And Bob's your uncle... Hmm, to be honest I hadn't tried. It works better than

Re: [cmake-developers] Obtaining header file dependencies of a source file manually

> I fail to see why that should not work. Producing LLVM bitcode from > C++ with Clang is just adding -emit-llvm flag, right? So, why can't > the SuperBuild configure the child build to use Clang and this flag? > And Bob's your uncle... Hmm, to be honest I hadn't tried. It works better than

Re: [CMake] [cmake-developers] Obtaining header file dependencies of a source file manually

On 12/01/2015 02:41 PM, Dan Liew wrote: >> Perhaps, but after regenerating the project the build tool will not >> re-load the build files and start building again. That will take >> an additional invocation. The number of iterations required is >> bounded only by the depth of dependency chains.

Re: [cmake-developers] [CMake] Obtaining header file dependencies of a source file manually

On 12/01/2015 02:41 PM, Dan Liew wrote: >> Perhaps, but after regenerating the project the build tool will not >> re-load the build files and start building again. That will take >> an additional invocation. The number of iterations required is >> bounded only by the depth of dependency chains.

[Cmake-commits] CMake branch, next, updated. v3.4.0-1567-gcfcc9d5

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via cfcc9d523d53ca01cdebe0e6c01e7e03b8fa8780 (commit) via

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

On 11/30/2015 02:16 PM, Michael Scott wrote: > Great, I've changed the nullptr references to NULL instead. Thanks. Applied with minor tweaks and merged to 'next' for testing: Merge topic 'cmake-W-options' into next https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cfcc9d52 -Brad --

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

> On 11/30/2015 11:54 AM, rle...@codelibre.net wrote: >> I do worry about the maintenance burden of hardcoding the information in >> the script. > > I do too. We already have to update the script for each Boost release. > This is among the reasons the work is better integrated with upstream >

[Cmake-commits] CMake branch, next, updated. v3.4.0-1570-gc95156f

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via c95156f85d7fa9a1cf1737d801a31b1bb74bae5b (commit) via

[Cmake-commits] CMake branch, next, updated. v3.4.0-1558-g3a00e36

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via 3a00e367994cde14d1a23a753b5e281e6342554a (commit) via

[Cmake-commits] CMake branch, next, updated. v3.4.0-1556-g67dbde4

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via 67dbde412032c40fec53387ac32e7361b208166b (commit) via

Re: [cmake-developers] Add CXX_STANDARD support for Intel C++ compilers

On 11/30/2015 02:13 PM, Levi Morrison wrote: > Hmm. Thanks. I applied it yesterday and merged to 'next' for testing: Features: Record standards and features for Intel C++ on UNIX https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=117d49b8 However, it fails the

Re: [cmake-developers] [PATCH] Fix building on musl-libc

On 11/30/2015 11:05 PM, Kylie McClain wrote: >> Does work here instead? > > Yes, appears to work just fine. Thanks. Applied accordingly: Include `sys/types.h` header to get `mode_t` https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=16f5d184 -Brad -- Powered by www.kitware.com Please

[cmake-developers] Please comment on ios-universal topic

Hello, During the last days I worked on the iOS Universal Install topic which now would benefit from a review. Especially the core changes could need a third pair of eyes: https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=8fb23b42cfc2fb7490e8645fff328add9c231713 I will now concentrate on

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

On 12/01/2015 10:58 AM, rle...@codelibre.net wrote: > I'd definitely like to see this for future Boost releases, though for > historical releases we're a bit stuck. I'll revisit the work I pointed to > and see if I can figure out bjam/boost-build and integrate this, since it > would effectively