Re: [CMake] FindMPI

Chuck, thanks for the response! The issue with your technique is that I don't want to put the burden on the users... I took a look at the FindMPI CMake module, and it seems as though you can set MPI_HOME to a list of directories to search. Would KitWare accept a pull request or a patch that

Re: [CMake] FindMPI

Thanks for the additional pointers Chuck! I am aware that it is preferred practice to pass the actual compilers rather than the wrappers as FC etc. but per Brad's advice I think Damian had setup the OpenCoarrays CMake build system to accept FC=mpif90 etc. and I'm in the process of migrating to the

Re: [CMake] FindMPI

Hi Zaak, When using CMake, it's generally best to use the actual compiler rather than any compiler wrappers (with Cray being the exception). Given that, set the CC, CXX, and FC environment variables to the actual compilers you want to use and then the MPI_{C,CXX,Fortan}_COMPILER CMake variables

Re: [CMake] [cmake-developers] C++11/C++14 doesn't work in check_cxx_source_compiles

On 11/24/2016 01:43 PM, Roman Wüger wrote: > Shouldn't this be done by CMAKE_CXX_STANDARD? Yes, this is a known problem with try_compile. It needs to learn to honor the CMAKE__STANDARD. CMake itself works around this problem in some cases, e.g. *

Re: [CMake] Executing python though CMake and linking libraries

On 2016-11-25 04:04, Kit Chambers wrote: > I have a Cmake custom target which runs a python script: > > add_custom_target(run > COMMAND python myscript.py > ) > > ... > > To me it looks like my LD_LIBRARY_PATH and DYLD_LIBRARY_PATH are not being > passed

Re: [CMake] FindMPI

Pass the following CMake options at configure time: -DMPI_C_COMPILER=/path/to/mpicc -DMPI_CXX_COMPILER=/path/to/mpiCC -DMPI_Fortran_COMPILER=/path/to/mpif90 -- Chuck Atkins Staff R Engineer, Scientific Computing Kitware, Inc. On Wed, Nov 23, 2016 at 6:05 PM, Zaak Beekman

Re: [CMake] Executing python though CMake and linking libraries

28.11.2016, 21:53, "Matthew Woehlke" : > On 2016-11-25 04:04, Kit Chambers wrote: >>  I have a Cmake custom target which runs a python script: >> >>  add_custom_target(run >>   COMMAND python myscript.py >>    ) >> >>  ... >> >>  To me it

Re: [CMake] VS2017 + CMake integration

Thanks for the feedback Marian! If/when you rebase to CMake 3.7, how will that package be delivered to Visual Studio customers? My real concern stems from basically our minimum required version of CMake for our specific scripts. The minimum is 3.7 due to the awesome Android integration added in

Re: [CMake] FindMPI

Hi Zaak, Sorry for the first mail being so abrupt, I didn't mean to hit "send" so soon. > I took a look at the FindMPI CMake module, and it seems as though you can > set MPI_HOME to a list of directories to search. > That's also another way of doing it, which would probably be easier than

Re: [CMake] [EXTERNAL]: Errors with cmake for VS2105 (update 3) + clang + nmake

I’m not sure if the toolset parameter will have any effect if you’re *not* also going to output vcxproj files, but can you try “v140_clang_c2” as the toolset? Parag Chandra Technical Lead, Mobile Team Mobile: +1.919.824.1410 Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA

Re: [CMake] VS2017 + CMake integration

Once we have it ready, it will be updated in-place in VS in one of the future releases. We can't commit yet that CMake 3.7 will be in VS 2017 RTW but it will definitely be in one of the VS Updates. VS ships every 1-2 months a preview update and every 3-4 months a major update. In parallel,

Re: [CMake] Executing python though CMake and linking libraries

I just got this working, so am posting to the list in case this helps someone else in the future. Essentially you invoke the python script through CMakes -E command and specify your library paths so it picks up all your shared libraries. Something like: add_custom_target(run

[cmake-developers] Fwd: cmVisualStudio10TargetGenerator should not generate a rule for an ImportLibrary for executables

Please consider the following patch for inclusion in cmake. The problem is that when a project contains a FOO.DLL and a FOO.EXE, the cmake generator tries to build FOO.LIB for both. The FOO.EXE does not need a FOO.LIB. $ diff -urp CMake-3.7.0-orig/ CMake-3.7.0 Only in CMake-3.7.0: build diff

Re: [cmake-developers] Questions about C++ version and third party libraries

On Sat, Nov 26, 2016 at 11:17 AM, mateusz janek wrote: > Hello CMake community, > > First of all, I want to say "Hello" to everyone, I am new to the CMake > developers community. > Hello and welcome! > I have some questions about developing rules, before I'll start to

Re: [cmake-developers] QtSDK integration

Hello all!Anybody known where Brad King?Or anybody can help me to review and merge !280, !281 and !282 MRs into 'next' for testing?7:04, 17 november 2016 г., Konstantin Podsvirov :Hi, dear CMake developers! Some of us actively using the Qt technology, but remain fans of

Re: [cmake-developers] Fwd: cmVisualStudio10TargetGenerator should not generate a rule for an ImportLibrary for executables

On Mon, Nov 28, 2016 at 2:41 PM, Lode Leroy wrote: > Please consider the following patch for inclusion in cmake. > > The problem is that when a project contains a FOO.DLL and a FOO.EXE, > the cmake generator tries to build FOO.LIB for both. > The FOO.EXE does not need a

Re: [cmake-developers] Fwd: cmVisualStudio10TargetGenerator should not generate a rule for an ImportLibrary for executables

On 11/28/2016 09:16 AM, Daniel Pfeifer wrote: > On Mon, Nov 28, 2016 at 2:41 PM, Lode Leroy wrote: >> The problem is that when a project contains a FOO.DLL and a FOO.EXE, >> the cmake generator tries to build FOO.LIB for both. >> The FOO.EXE does not need a FOO.LIB. > Please see

[Cmake-commits] CMake branch, master, updated. v3.7.0-644-g56c5c8e

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, master has been updated via 56c5c8e17aab80fe006d3de064d322dc31e8f25b (commit) via

[Cmake-commits] CMake branch, master, updated. v3.7.0-649-g4093bd4

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, master has been updated via 4093bd4025e65bdc75254bc7d08a675b10808a22 (commit) via

[cmake-developers] GitLab speed

Hello all, While I appreciate having an integrated workflow and well defined contributing rules is useful for CMake I am finding it hard to get used to GitLab. The main reason is speed. Creating merge requests, moving around the interface and even pushing to repos seems to be much slower than

[Cmake-commits] CMake branch, next, updated. v3.7.0-1369-g03ed0e9

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 03ed0e9279261bc7967d77b19ab9d71d3a929512 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.7.0-1373-g23e8657

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 23e8657e5854ff3fef364ec490a14fb06556f04d (commit) via

[Cmake-commits] CMake branch, next, updated. v3.7.0-1371-g0235eda

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 0235eda8011ac6f8bdafa2a2e2ae8044c47556dc (commit) via

[Cmake-commits] CMake branch, next, updated. v3.7.0-1376-gcc653be

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 cc653bea23a94e8c494203954954efd319d31cda (commit) via

Re: [cmake-developers] QtAutogen suggestions

On 11/25/2016 05:37 PM, Sebastian Holtermann wrote: > There are some issues with QtAutogen that still bother me and > that I would like to change. Great! We currently have no dedicated maintainer for it and I have little understanding of the tools and use cases associated with it myself. It

Re: [cmake-developers] C++11/C++14 doesn't work in check_cxx_source_compiles

On 11/24/2016 01:43 PM, Roman Wüger wrote: > Shouldn't this be done by CMAKE_CXX_STANDARD? Yes, this is a known problem with try_compile. It needs to learn to honor the CMAKE__STANDARD. CMake itself works around this problem in some cases, e.g. *

Re: [cmake-developers] QtAutogen suggestions

Am 28.11.2016 um 15:57 schrieb Brad King: > On 11/25/2016 05:37 PM, Sebastian Holtermann wrote: >> There are some issues with QtAutogen that still bother me and >> that I would like to change. > > Great! We currently have no dedicated maintainer for it and I have > little understanding of the

[Cmake-commits] CMake branch, next, updated. v3.7.0-1359-g398ab66

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 398ab66bf2da85aa50a5fa9638a4cff14ec6d024 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.7.0-624-g8a975ef

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, master has been updated via 8a975efc94518c93124d66a7a6626d8ab13f9561 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.7.0-1355-g70bd7d1

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 70bd7d16c57b3929f06b7faa5141efd4e4b6c031 (commit) via

Re: [cmake-developers] QtAutogen suggestions

Am 28.11.2016 um 17:00 schrieb Brad King: > On 11/28/2016 10:25 AM, Sebastian Holtermann wrote: >> I'm going ahead then. > > Thanks. BTW, please sign up for a gitlab.kitware.com account > (optionally via GitHub OAuth) so that we can include you in > discussion of related issues. For example:

[Cmake-commits] CMake branch, next, updated. v3.7.0-1364-gd98f717

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 d98f7178adc3cb8ea3f46302e3efaf2f58088a8f (commit) via

[Cmake-commits] CMake branch, next, updated. v3.7.0-1366-gf86efd5

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 f86efd538055a50001396eed9648f151a0a54088 (commit) via

Re: [cmake-developers] QtAutogen suggestions

On 11/28/2016 10:25 AM, Sebastian Holtermann wrote: > I'm going ahead then. Thanks. BTW, please sign up for a gitlab.kitware.com account (optionally via GitHub OAuth) so that we can include you in discussion of related issues. For example: * https://gitlab.kitware.com/cmake/cmake/issues/16460

Re: [cmake-developers] QtSDK integration

On 11/28/2016 08:49 AM, Konstantin Podsvirov wrote: > Anybody known where Brad King? > > Or anybody can help me to review and merge !280, !281 and !282 MRs > into 'next' for testing? I was on vacation for the US Thanksgiving holiday. I'll get to these when I can. Thanks, -Brad -- Powered by

Re: [cmake-developers] GitLab speed

On 11/28/2016 02:27 PM, Harry Mallon wrote: > moving around the interface and even pushing to repos seems to be > much slower than the equivalent thing on github. Has it only been today or the last few days that you've noticed this? It does feel slower today than usual. I'll check with our

[Cmake-commits] CMake branch, next, updated. v3.7.0-1380-g35edbdb

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 35edbdb02c0566eb56c3b649450caf68607b5216 (commit) via

Re: [cmake-developers] QtSDK integration

Well, thank you Brad!22:14, 28 november 2016 г., Brad King :On 11/28/2016 08:49 AM, Konstantin Podsvirov wrote: Anybody known where Brad King? Or anybody can help me to review and merge !280, !281 and !282 MRs into 'next' for testing?I was on vacation for the US Thanksgiving

[Cmake-commits] CMake branch, master, updated. v3.7.0-650-g2f7e05f

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