Hi all,
I used to do parallel build for my nightly with ctest by putting
MAKECOMMAND:STRING=/usr/bin/make -i -j8
in my .cmake script.
Since a few month ago, it does not seem to work anymore. This is
clearly visible on my submission to the ITK dashboard:
http://www.cdash.org/CDash/buildSummary.php
On 2010-07-20 00:51+0200 Michael Hertling wrote:
On 07/18/2010 10:14 PM, Alan W. Irwin wrote:
(1) http://public.kitware.com/Bug/view.php?id=10718 is fixed. In my
view this bug has been the source of much CMake find trouble for a long
time, and I hope the CMake developers make it a high priorit
On 07/18/2010 10:14 PM, Alan W. Irwin wrote:
> On 2010-07-18 12:07-0700 Branan Purvine-Riley wrote:
>
>> Unfortunately, I can't think of a way to get out of using hardcoded version
>> lists, since python is often in specific locations (or has a specific
>> executable
>> name) based on its version
On 07/18/2010 09:07 PM, Branan Purvine-Riley wrote:
> On Sunday 18 July 2010 09:15:17 Michael Hertling wrote:
>> On 07/18/2010 06:50 AM, Branan Riley wrote:
>>> I've mad a very cursory effort to add Python 3 support to CMake. All
>>> I've done so far is take FindPythonLibs and FindPythonInterp, and
On 07/19/2010 02:54 PM, Michael Jackson wrote:
On Jul 19, 2010, at 4:28 PM, Michael Wild wrote:
On 19. Jul, 2010, at 19:59 , Michael Jackson wrote:
Wonder why I have never seen this before but with CMake 2.8.x and a
Qt4 based project on OS X when finding the Qt4 frameworks only the
release
On Jul 19, 2010, at 4:28 PM, Michael Wild wrote:
On 19. Jul, 2010, at 19:59 , Michael Jackson wrote:
Wonder why I have never seen this before but with CMake 2.8.x and a
Qt4 based project on OS X when finding the Qt4 frameworks only the
release version is found, ie, the Debug version that
On 19. Jul, 2010, at 19:59 , Michael Jackson wrote:
> Wonder why I have never seen this before but with CMake 2.8.x and a Qt4 based
> project on OS X when finding the Qt4 frameworks only the release version is
> found, ie, the Debug version that is located inside the framework is NOT
> found b
Thanks very much again for your help. I now have enough
to fix my problem. Some more info below that might be of
general interest.
On 7/19/10 12:43 PM, Brad King wrote:
On 07/19/2010 11:46 AM, John R. Cary wrote:
and I passed the correct fortran, so I also know that what is
here:
numb
On 07/19/2010 11:46 AM, John R. Cary wrote:
> So the lapack libraries are actually needed as a dependency of
> Trilinos, another C++ library, which does the calling of the
> symbols, and it must get those right, because if I add them to
> the link line, then all links and runs.
>
> Now I happen to
>linking your executable to those libs or are you doing
>something like "dlopen" inside your application?
>
>--
>Erk
>Membre de l'April - « promouvoir et défendre le logiciel libre » -
>http://www.april.org
Thanks for the response. The executable uses dlopen at runtime and was
pointing to the "s
Wonder why I have never seen this before but with CMake 2.8.x and a
Qt4 based project on OS X when finding the Qt4 frameworks only the
release version is found, ie, the Debug version that is located inside
the framework is NOT found by default.
My question is: is this a bug, a "feature" or
2010/7/19 :
> When I do an in-source build, everything runs ok. However, I have
> issues with an out-of-source build. One of my libraries uses another
> one of my libraries. When I run the executable it complains "cannot
> open shared object file: No such file or directory."
linking your execu
When I do an in-source build, everything runs ok. However, I have
issues with an out-of-source build. One of my libraries uses another
one of my libraries. When I run the executable it complains "cannot
open shared object file: No such file or directory." It's looking for
the library in the sou
Thanks for your response. More below.
On 7/19/2010 9:06 AM, Brad King wrote:
Can I force the addition of these libraries without referencing
them explicitly?
One workaround is to list a dummy .F file just to tell CMake that
Fortran will be involved at link time. I call it a workaround
On 07/19/2010 09:37 AM, John Cary wrote:
> So this is very cool.
Thanks!
> Somehow it is not quite working for me. My project is entirely
> C++ with C and C++ libraries
All the magic I just described is for projects that mix Fortran
and C++ themselves. It will not handle this case because the
So this is very cool.
Somehow it is not quite working for me. My project is entirely
C++ with C and C++ libraries, but it links to a system lapack
and blas that reference the fortran libraries, so my final link
has the errors,
trilinos/lib/libml.a /contrib/trilinos/lib/libamesos.a
/contrib/tr
On 07/18/2010 09:10 PM, John Cary wrote:
> Thanks for your help with this. I did
> INCLUDE(FortranCInterface), but I did not
> see in CMakeCache.txt any variables that
> might contain the fortran libs needed by
> the C/C++ linkers (e.g., libgfortran).
> Did I miss something?
The FortranCInterface
17 matches
Mail list logo
