It has been merged into master:
https://github.com/martine/ninja/commit/abd33d5e3b11ae5470f62cbce49723a4cf62870d
So you can now use the normal Ninja for your project.
Cheers,
-Nico
2012/3/14 Chuck Atkins chuck.atk...@kitware.com:
Yep. That fixed it. Thanks!
Chuck Atkins
RD Engineer,
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13066
==
Reported By:Kashif Rasul
Assigned To:
On 3/24/2012 12:41 AM, Rolf Eike Beer wrote:
I have seen a strange behaviour on my (openSUSE) Linux host running on AMD64.
Sometimes during my Find* module tests libraries in /usr/lib64 were not found.
It took me a while until I noticed what was going on there:
FIND_LIBRARY_USE_LIB64_PATHS is
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13067
==
Reported By:Matthew McCormick
Assigned To:
On 3/26/2012 10:49 AM, Rolf Eike Beer wrote:
For the beginning I added 2 obvious cleanups to the lib64-cleanup topic on
stage. If noone objects I'll merge them to next soon.
Thanks. In FindBLAS:
if (WIN32)
set(_libdir ENV LIB)
elseif (APPLE)
-set(_libdir /usr/local/lib
Rolf Eike Beer wrote:
ok, I now have:
find_path(VAR header.h
HINTS /opt/p1
PATHS /opt/p2
PATH_SUFFIXES foo)
This would search in /usr/include, /usr/foo, /opt/p1/foo, /opt/p2/foo, but
neither in /opt/p1/include nor /opt/p2/include. Correct?
As far as I understand, it will search:
Am Montag, 26. März 2012, 11:01:38 schrieb Brad King:
On 3/26/2012 10:49 AM, Rolf Eike Beer wrote:
For the beginning I added 2 obvious cleanups to the lib64-cleanup topic
on stage. If noone objects I'll merge them to next soon.
Thanks. In FindBLAS:
if (WIN32)
set(_libdir ENV
On 3/26/2012 11:49 AM, Rolf Eike Beer wrote:
Thanks, fixed. And added a patch that removes this in a bunch of other modules.
Nice. Looks good so far. I noticed in the context of some of your
changes lines like
/usr/local/lib/fltk2
/usr/lib/fltk2
This pattern can be replaced by
On 3/26/2012 1:35 PM, Rolf Eike Beer wrote:
Well, that is in fact an interesting question. If /usr is in the default
paths list and lib is a default suffix, will specifying fltk2 as suffix
result in /usr, /usr/lib, and /usr/fltk2, or will also /usr/lib/fltk2 be
searched. The latter would mean
On Saturday 24 March 2012, Rolf Eike Beer wrote:
I have seen a strange behaviour on my (openSUSE) Linux host running on
AMD64. Sometimes during my Find* module tests libraries in /usr/lib64 were
not found. It took me a while until I noticed what was going on there:
FIND_LIBRARY_USE_LIB64_PATHS
On Sat, 24 Mar 2012 08:53:04 -0400, David Cole said:
The answer to that stackoverflow question recommends using
clang/clang++ instead. (I have not tried this yet myself, but would
not be entirely surprised to find out it's correct. I have observed
the zero coverage phenomenon on my own Mac
On Sat, 24 Mar 2012 17:34:22 +, NoRulez said:
But i?t seems that there is something missing, because I also get the
message that no coverage files were found for some projects:
-- Coverage Continuous --
Cannot find any coverage files. Ignoring Coverage request.
Here are my version
Hello,
I am building cmake on RHEL6. I need a version higher than the one
that comes with RHEL6.
After doing bootstrap and make, I get an error with make install:
/home/sm/software/cmake/cmake-2.8.7/Bootstrap.cmk/cmake:
/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required
2012/3/26 Mirko Vukovic mirko.vuko...@gmail.com:
Hello,
I am building cmake on RHEL6. I need a version higher than the one
that comes with RHEL6.
After doing bootstrap and make,
Did you try to build cmake with cmake instead?
I get an error with make install:
On Mon, Mar 26, 2012 at 2:30 PM, Eric Noulard eric.noul...@gmail.com wrote:
2012/3/26 Mirko Vukovic mirko.vuko...@gmail.com:
Hello,
I am building cmake on RHEL6. I need a version higher than the one
that comes with RHEL6.
After doing bootstrap and make,
Did you try to build cmake with
2012/3/26 Mirko Vukovic mirko.vuko...@gmail.com:
On Mon, Mar 26, 2012 at 2:30 PM, Eric Noulard eric.noul...@gmail.com wrote:
2012/3/26 Mirko Vukovic mirko.vuko...@gmail.com:
Hello,
I am building cmake on RHEL6. I need a version higher than the one
that comes with RHEL6.
After doing
Hi,
I would like to use CDash sub projects when I submit to the dashboard, but
I don't find anywhere instructions on how to send the LABEL property.
I set up the LABEL property for my executables and their tests, and after
the execution tests I already get a summary according to these labels.
2012/3/26 Mirko Vukovic mirko.vuko...@gmail.com:
I can certainly try again (remove /usr/local from PATH variables).
But as I am not familiar with cmake, can you please spell out for me
how to use it? I am much more used to make configure.
I tried with cmake -i, but I not sure if I did
2012/3/26 Eric Noulard eric.noul...@gmail.com:
2012/3/26 Robert Dailey rcdailey.li...@gmail.com:
Ever since I started using CMake, I always assumed that the WIN32 variable
represented what system CMake is currently running on. Looking more
carefully at the documentation, however, it seems this
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 489b0e22c9af690d7fb1cf53f8ffa495002d8e48 (commit)
via
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 4b37c3cb6fe6282e82b8d5bd52e51254153be2f7 (commit)
via
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 cee132f0cea0c8ff7e6cb0c0ec3b3c3987c4bc5c (commit)
via
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 77ec098b44ea036078a574754b6c935837a2fd75 (commit)
from
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 e26272157599349803ca853abab89bc7c4bc8544 (commit)
via
24 matches
Mail list logo
