Since I haven't worked with MPI, I don't think I can help much. Try
using the message command to dump variable contents
e.g. message(STATUS "CMAKE_C_FLAGS = ${CMAKE_C_FLAGS}")
You may need to add includes explicitly with the "include_directories"
(or similar) command. Hopefully some else using MPI
Can you verify that *${MPI_C_INCLUDE_PATH} is actually set?
I normally use 'printf' debugging to find out: message(WARNING "HELLO:
**${MPI_C_INCLUDE_PATH}*")
Regards,
Micha
On 03/18/2014 07:34 AM, Bibrak Qamar wrote:
> Thanks for the help.
>
> I did that but still the error persists.
>
> The C co
By quick Google search, I meant for "cmake project command". Not sure
how I determined this originally. It was a long time ago. Probably read,
re-read, and re-read the doco - it wasn't obvious. Anyway, hope it helps.
On 18/03/14 17:22, Bruce Cartland wrote:
> Try the project command
>
> * project
Thanks for the help.
I did that but still the error persists.
The C compiler identification is GNU
-- Check for working C compiler:
/export/home/bibrak/MPJExpress_Project/work/programs/installs/bin/gcc
-- Check for working C compiler:
/export/home/bibrak/MPJExpress_Project/work/programs/installs/
Try the project command
* project(yourProjectName C)
It's what I use.
Quick Google found this
* http://www.cmake.org/cmake/help/cmake2.6docs.html#command:project
On 18/03/14 17:09, Bibrak Qamar wrote:
> Hi,
>
> I am using cmake to create Makefile. I am using MPI in my project but
> I only wan
Hi,
I am using cmake to create Makefile. I am using MPI in my project but I
only want to use the C (mpicc) not C++ (mpicxx) following is the
CMakeLists.txt:
I have tested it but on some platforms it seems that it only detects the
C++ mpi (mpicxx) and uses its libraries. This creates errors (mpi.h
Thanks David, now it works, seems to be cache issue
On Fri, Mar 14, 2014 at 4:46 PM, David Cole wrote:
> If you start with a clean directory in each case, do you get the same
> results?
>
> (i.e. -- is the result of the first run cached, and re-used despite your
> change of variable value...?)
I'm upgrading my build from 2.8.8 to the latest toolset.
At this stage I've only tried on Windows 2008 Server R2 Standard SP1 and
Windows Server 2003 R2 SP2 (my Linux/Mac boxes are currently broken).
The particular part which fails is packaging the source - which uses the
ZIP generator
cpack --c
Why do you want to do that?
The ExternalProject will not rebuild correctly when you modify these
source files... Unless you are forcing the build step to run every
single time.
You are using ExternalProject as if it were NOT external. Why not just
use add_subdirectory instead and have an "in
I've added the source files with "file(GLOB_RECURSE..." and set source file
property for each of these files with HEADER_FILE_OLY to TRUE.
It seems to work, but I'm not sure if this is the right way.
> Am 17.03.2014 um 08:49 schrieb NoRulez :
>
> Hello,
>
> if I add an external project with E
Hello,
if I add an external project with ExternalProject_Add, is it possible to show
the sources of that project in Visual Studio too?
I don't know if this is the reason, but currently the projects type is set to
utility.
Best Regards
--
Powered by www.kitware.com
Please keep messages on-to
11 matches
Mail list logo