Hi Alex,
On Thu, 2010-06-24 at 22:52 +0200, Alexander Neundorf wrote:
On Thursday 24 June 2010, Marcel Loose wrote:
Oops! Forgot to CC to the list.
Hi Tod,
I'll try to answer some of your questions below inline (I've snipped
off
parts of your mail). We're also using a BlueGeneP,
Hi!
We have a problem on Windows with Visual Studio projects and the Intel Fortran
11.1 compiler.
We have a project the contains Fortran sources and links a static C++ library. So in Visual Studio this project is a Fortran project. With update 38
of the Fortran compiler this was working
Dear all,
I am using valgrind to debug a framework which depends on several other
underlying frameworks to function properly. As a result my memory checking
turns up thousands of errors. I only want to see errors that arise from my
framework. This is figured can be done by simply looking for a
Hi,
is there a way to tell CMake how to compile files based on their
extension?
For example, here's a make rule to build an object file from a *.lst file:
%.o : %.lst
echo #include \irx_imports.h\ build-imports.c
cat $ build-imports.c
$(IOP_CC) $(IOP_CFLAGS) build-imports.c -o $@
I can't really think of a better way to tackle the problem...
But I will make this one observation:
If these underlying frameworks you depend on produce *thousands* of valgrind
errors, do you really want to be depending on them?
(Serious question, not trying to be flippant... It would make me
Den 23-06-2010 23:39, Alexandre Gramfort skrev:
I'm deploying a cmake project on windows and I have a few questions
concerning the
installer generated by cpack using NSIS
- is it possible to remove the mention create desktop icon since the
installer contains only command line tools?
- is it
Just to follow my own advice and give the answer to the question I sent
here.
The basic problem is this: Can you add a file to the installer that
isn't uninstalled?
Answer: No, this is impossible. Anything short of patching the CMake
sourcecode is going to fail. Not even copying the NSIS
On 06/25/2010 03:42 PM, David Cole wrote:
I would have thought it was a git commit hash... but I cannot find it at:
http://cmake.org/gitweb?p=cmake.git;a=summary
Perhaps it's in another git repo?
No, it's in your first-order repository:
git clone git://cmake.org/cmake.git
cd cmake
git
On Fri, Jun 25, 2010 at 9:42 AM, David Cole david.c...@kitware.com wrote:
I would have thought it was a git commit hash... but I cannot find it at:
http://cmake.org/gitweb?p=cmake.git;a=summary
Perhaps it's in another git repo?
Oops. Thanks Michael, for pointing us to
Same for all project configurations like environment variables and others...
I'm also looking for a solution to that problem. I guess the solution would
be to make these settings available as CMake variables that are remembered
by the CMake cache. So far I haven't found a way to do that, if it is
I have created a simple CMakeLists.txt file:
FIND_FILE(tmp_h tmp.h PATHS /cygwin/home/cary/tmp/tmp1)
MESSAGE(tmp_h = ${tmp_h}
and inside of tmp1 I have put the file tmp.h.
This works fine. The output contains
tmp_h = /cygwin/home/cary/tmp/tmp1/tmp.h
Then I create a lnk and rename it
In
On 2010-06-25 15:45:37 +0200, Michael Hertling said:
On 06/25/2010 03:17 PM, Janosch Peters wrote:
On 2010-06-21 07:01:36 +0200, Michael Hertling said:
8d87d12
What's that? Leet speak?
No, these are the first seven and sufficiently unambiguous digits of
the SHA-1 sum of the commit in
For the cmake valgrind dashboard, we use the script seen here:
http://www.cdash.org/CDash/viewNotes.php?buildid=647028
If you look at it, you will see that we list a bunch of tools that produce
valgrind output that we are not interested in having show up on the CMake
dashboard.
(For example,
On 6/25/2010 7:47 AM, David Cole wrote:
I can't really think of a better way to tackle the problem...
But I will make this one observation:
If these underlying frameworks you depend on produce *thousands* of
valgrind errors, do you really want to be depending on them?
(Serious question, not
On 6/25/2010 10:16 AM, David Cole wrote:
For the cmake valgrind dashboard, we use the script seen here:
http://www.cdash.org/CDash/viewNotes.php?buildid=647028
If you look at it, you will see that we list a bunch of tools that
produce valgrind output that we are not interested in having show up
On Jun 25, 2010, at 9:11 AM, Janosch Peters wrote:
On 2010-06-25 15:45:37 +0200, Michael Hertling said:
On 06/25/2010 03:17 PM, Janosch Peters wrote:
On 2010-06-21 07:01:36 +0200, Michael Hertling said:
8d87d12
What's that? Leet speak?
No, these are the first seven and sufficiently
Thanks for the suggestions, but i already went down these paths. The problem is
my logs in xml format on an average go above 100 MB of output, with
gen-suppressions i get 300MB output files and the suppressions file generated
out of these is again way too big for my liking.
If only valgrind had
On 25. Jun, 2010, at 16:32 , Mark Moll wrote:
On Jun 25, 2010, at 9:11 AM, Janosch Peters wrote:
On 2010-06-25 15:45:37 +0200, Michael Hertling said:
On 06/25/2010 03:17 PM, Janosch Peters wrote:
On 2010-06-21 07:01:36 +0200, Michael Hertling said:
8d87d12
What's that? Leet speak?
On 2010-06-25 16:32:38 +0200, Mark Moll said:
On Jun 25, 2010, at 9:11 AM, Janosch Peters wrote:
Ok. But the python dilemma still remains:
1. FindPythonInterp and FindPythonLibs might still produce inconsistent
results (e.g. libs and interpreter of different python versions)
2. AFAIK you
On 2010-06-25 16:58:47 +0200, Michael Wild said:
However, I think it's really difficult to guarantee consistency. If the
code to be compiled contains stuff like the following
#ifdef __APPLE__
#include Python/Python.h
#else
#include Python.h
#endif
the compiler will compile against the latest
On Fri, Jun 25, 2010 at 08:23:06AM -0400, cmake-requ...@cmake.org wrote:
So is there any way in cmake to enforce Visual Studio to use link.exe instead
of xilink.exe?
grep -i LINK /usr/share/cmake-2.8/Modules/Platform/*|less
yields a ton of link-related CMake variables during platform setup,
on the
dashboard. (http://my.cdash.org/viewTest.php?onlyfailedbuildid=77416)
$ ctest -D Experimental -R 3d
Site: starfish.megason-lab.hms
Build name: OSX-10.5-gcc4.0.1
Create new tag: 20100625-1503 - Experimental
Configure project
Each . represents 1024 bytes of output
. Size of output: 0K
On Jun 25, 2010, at 10:05 AM, Janosch Peters wrote:
On 2010-06-25 16:32:38 +0200, Mark Moll said:
On Jun 25, 2010, at 9:11 AM, Janosch Peters wrote:
Ok. But the python dilemma still remains:
1. FindPythonInterp and FindPythonLibs might still produce inconsistent
results (e.g. libs and
Marcus Sindermann wrote:
Now we want to use update 65 of the Fortran compiler. This update
enforces Visual Studio to use the Intel Fortran xilink for linking
Fortran projects.
CMake just generates the .vfproj file and then VS is responsible for
the actual build. If the Fortran plugin is
Andreas Mohr wrote:
On Fri, Jun 25, 2010 at 08:23:06AM -0400, cmake-requ...@cmake.org wrote:
So is there any way in cmake to enforce Visual Studio to use link.exe
instead of xilink.exe?
grep -i LINK /usr/share/cmake-2.8/Modules/Platform/*|less
yields a ton of link-related CMake variables
and reports the vtk leaks if you check on the dashboard.
(http://my.cdash.org/viewTest.php?onlyfailedbuildid=77416)
$ ctest -D Experimental -R 3d
Site: starfish.megason-lab.hms
Build name: OSX-10.5-gcc4.0.1
Create new tag: 20100625-1503 - Experimental
Configure project
Each . represents
On 25. Jun, 2010, at 17:14 , Janosch Peters wrote:
On 2010-06-25 16:58:47 +0200, Michael Wild said:
However, I think it's really difficult to guarantee consistency. If the code
to be compiled contains stuff like the following
#ifdef __APPLE__
#include Python/Python.h
#else
#include
James Amundson wrote:
This bug is a favorite of mine. It has been reported on the mailing list
before. It is also in the bug tracker:
http://public.kitware.com/Bug/view.php?id=10312nbn=1#bugnotes
In each case a patch has been given to solve the problem. Nothing has
happened, however.
The
Brad King wrote:
Can you modify the project file through the IDE by hand to chose the
linker you want?
s/chose/choose/
To be more clear, if it is possible to modify the project in the IDE
by hand to change the linker, then we can teach CMake to generate the
project file accordingly. If it is
On 6/10/2010 2:34 PM, Ed Loper wrote:
I have a CMake project that works fine with CMake 2.6, but when I build
Visual Studio output with CMake 2.8, it doesn't seem to get the target
library linking information quite right. [...]
I managed to track down the cause of this problem. It can be
On Jun 24, 2010, at 2:40 AM, Michael Hertling wrote:
On 06/24/2010 08:29 AM, Tom Birch wrote:
Hi,
I'm trying to invoke the C compiler in cmake as would happen with an
add_excecutable command, but I don't want to generate an object file.
Basically I have a script which generates a c
Alexander Neundorf wrote:
On Wednesday 23 June 2010, Todd Gamblin wrote:
3a. First, using this setup, FindMPI fails because the last library it
needs is in /bgsys/drivers/ppcfloor/runtime/SPI, not
/bgsys/drivers/ppcfloor/runtime/SPI/lib. CMAKE_FIND_ROOT_PATH seems to
assume that its
On Fri, Jun 25, 2010 at 3:00 PM, Ed Loper elo...@bbn.com wrote:
On 6/10/2010 2:34 PM, Ed Loper wrote:
I have a CMake project that works fine with CMake 2.6, but when I build
Visual Studio output with CMake 2.8, it doesn't seem to get the target
library linking information quite right. [...]
On 06/25/2010 01:40 PM, Brad King wrote:
James Amundson wrote:
This bug is a favorite of mine. It has been reported on the mailing list
before. It is also in the bug tracker:
http://public.kitware.com/Bug/view.php?id=10312nbn=1#bugnotes
In each case a patch has been given to solve the
On 2010-06-25 18:36:06 +0200, Michael Wild said:
AFAIK all directories you give gcc with the -I option will be
searched _before_ the standard include paths or C_INCLUDE_PATH. So I
think you do have control over what is included. But I know almost
nohting about all the compiling/linking stuff,
On Jun 25, 2010, at 12:06 PM, Brad King wrote:
Alexander Neundorf wrote:
On Wednesday 23 June 2010, Todd Gamblin wrote:
3a. First, using this setup, FindMPI fails because the last library it
needs is in /bgsys/drivers/ppcfloor/runtime/SPI, not
/bgsys/drivers/ppcfloor/runtime/SPI/lib.
I'm using add_excecutable to generate a .s file which I then parse to generate
a header file. This all works fine and all the dependencies seem to be working,
but it gets built every time, even if nothing has changed.
I have a function to generate the asm file:
function (make_asm_file source
On 06/25/2010 04:11 PM, Janosch Peters wrote:
On 2010-06-25 15:45:37 +0200, Michael Hertling said:
On 06/25/2010 03:17 PM, Janosch Peters wrote:
On 2010-06-21 07:01:36 +0200, Michael Hertling said:
8d87d12
What's that? Leet speak?
No, these are the first seven and sufficiently
On 06/26/2010 01:09 AM, Tom Birch wrote:
I'm using add_excecutable to generate a .s file which I then parse to
generate a header file. This all works fine and all the dependencies seem to
be working, but it gets built every time, even if nothing has changed.
I have a function to generate
On Jun 23, 2010, at 2:10 PM, Alexander Neundorf wrote:
3a. First, using this setup, FindMPI fails because the last library it
needs is in /bgsys/drivers/ppcfloor/runtime/SPI, not
/bgsys/drivers/ppcfloor/runtime/SPI/lib. CMAKE_FIND_ROOT_PATH seems to
assume that its elements are just above a
Some small additions to the path information I posted below:
I believe the original GNU/POSIX runtime libraries for the compute nodes are
located here:
/bgsys/drivers/ppcfloor/gnu-linux/powerpc-bgp-linux
So you'll need this directory in your prefixes to detect things like libpthread
Hi all,
I tend to agree to this observation in general about CMake too. I had to do a
lot of reading and experimentation to make it do what I wanted, even though at
the end of the day, the resulting CMakeList.txt file is very simple.
I do understand why this is so. As can be seen by
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 e548a88579a021598bcf0fc703246d265e7cc605 (commit)
via
43 matches
Mail list logo
