The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14943
==
Reported By:Thierry Valentin
Assigned To:
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14944
==
Reported By:Thierry Valentin
Assigned To:
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14945
==
Reported By:Richard Patek
Assigned To:
On Wed, 28 May 2014 16:17:39 -0400
Brad King brad.k...@kitware.com wrote:
On 05/28/2014 01:20 PM, Alessandro Di Federico wrote:
Hi, I'm working on a quite big project, namely LLVM. As you can
imagine, launching a `make install` it's quite time consuming, in
particular in Debug builds.
On 05/29/2014 08:06 AM, Alessandro Di Federico wrote:
OK, I'll come up with a patch. The only thing is that --reflink has
been introduced around 2009, in coreutils 7.6 (we are currently at
8.22). Is it OK to assume we have such coreutils or some kind of
(build-time?) detection is needed?
On 05/28/2014 10:24 PM, Greg Jung wrote:
I found on Linux, FindFreetype is not found because it is invoked the
lower-case f'.
Propose to change the name to Findfreetype.
Call find_package(Freetype) in your project to get the case right.
-Brad
--
Powered by www.kitware.com
Please keep
On 05/28/2014 05:19 PM, J Decker wrote:
CMake would much rather use full paths rather than -L/-l because of
ambiguity problems.
I can get around abguity by ordering the order of -L entries..
CMake versions prior to 2.6 always did that. We had no end of trouble
with the wrong library files
On 05/08/2014 02:34 PM, James Bigler wrote:
CUDA_FILES =
/Users/jbigler/code/FindCUDA/build-cmake-git/src/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_test_bin.cu.o
When I try to compile cuda_compile_example I get this, though:
make[2]: *** No rule to make target
28.05.2014 20:17 пользователь Nils Gladitz nilsglad...@gmail.com написал:
On 28.05.2014 18:01, Vadim Zhukov wrote:
I assumed that because people kept removing the soname options for their
Android toolchains that SONAMEs aren't supported at all.
It however looks like they just can't
Hello,
Part of the design of the compile features concept is that it may be used to
require compiler extensions. The extensions are enabled by default for GNU
and Clang - that is, the option -std=gnu++98 is implied. Passing -std=c++98
disables the extensions, as do other language standard
On 05/29/2014 12:32 PM, Vadim Zhukov wrote:
I was not aware of such issue before that question. :) Yes, paths are
written in NEEDED entries if requested, that's what CMake does for
external libraries (outside project). Internal libraries are linked
by name, though, allowing to relocate the
On 05/29/2014 12:50 PM, Stephen Kelly wrote:
I recommend we change C{,XX}_EXTENSIONS to 'on-by-default'.
The user may still set it to FALSE explicitly in order to use a possible
non-extended compile option where available.
Fine with me. It matches the compiler behavior of having extensions
12 matches
Mail list logo
