On 5/9/2014 11:58 AM, David Cole wrote:
If you use get_filename_component in conjunction with paths that contain
".." or Windows-style component separators ("\"), you can always clean
up the resulting string with the "ABSOLUTE" argument to
get_filename_component. It will collapse any "/../" or "/
On Fri, May 09, 2014 at 15:19:51 -0400, Brad King wrote:
> Ninja: Fix deptype for Intel compiler on Linux
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=54535f47
Would this be cleaner:
https://github.com/mathstuf/CMake/commit/9523d2a55c99fb0910531ae7160b099faeab6638
It would allow f
On 05/09/2014 01:56 PM, Thompson, K T wrote:
> -- The CXX compiler identification is Intel 14.0.2.20140120
[snip]
> ninja: fatal: unknown deps type 'msvc'
Thanks for trying the release candidate.
The problem was introduced here:
Ninja: deptype msvc for Intel's compiler on Windows
http://cmak
I wonder if anyone else has come into this kind of situation.
We are restructuring how some of our libraries are structured on disk to be
more modular.
Previously, we had all of the project names defined in a CMakeList.txt that
then would call to add the subdirectories that are needed. This wo
There seems to be an issue with the Ninja generator in CMake-3.0.0-rc4 when
$CXX points to the Intel C++ compiler (on Linux). Can anyone confirm this
deficiency?
Here is my reproducer:
# CMakeLists.txt
CMAKE_MINIMUM_REQUIRED(VERSION 3.0)
PROJECT( hw CXX )
add_executable( hw hw.cc )
// hw.cc
#i
I'm in the process of evaluating cmake to replace our current
build system which is based solely on gnu make with custom
makefiles for each operating system we deal with. If the
functionality described in Bug 3812 @
http://www.cmake.org/Bug/view.php?id=3812
were implemented cmake would be able
Hi Nils,
thanks for your answer. Your proposal is a valid work-around, but the
summary entry would remain missing.
In general I am more interested in directly fixing the problem in CMake.
Bye
Christoph
Am 09.05.2014 12:25, schrieb Nils Gladitz:
> On 05/09/2014 12:05 PM, Christoph Grüninger wrote:
On 05/09/2014 12:05 PM, Christoph Grüninger wrote:
But if A is not installed, find_package generates an annoying and
disruptive warning message. I always check what went wrong to simply
find out, that I have not provided the path to A, just as I wanted.
I would prefer to get a single line statin
Hi CMake fellows,
I have two pieces of software. Software A is an optional dependency of
B. Following the way CMake intends, A provides a a-config.cmake. B does
not have a FindB.cmake because A provides the config file [1]. B has a
UseB.cmake which calls find_package(A). This works well in the case
Also, one more comment on your technique:
If you use get_filename_component in conjunction with paths that
contain ".." or Windows-style component separators ("\"), you can
always clean up the resulting string with the "ABSOLUTE" argument to
get_filename_component. It will collapse any "/../"
> Does CMAKE_CXX_COMPILER always provide the full path name of the
> compiler, when we use the current version of CMake (2.8.12.2)? In the
> past it did not, apparently, as a CMakeCache.txt file generated by
> CMake 2.8.8 simply had "cl" as compiler file path
I think now it does, but I'm not 100%
Thanks for suggesting CMAKE_CXX_COMPILER, David. Cool! Indeed, the
following appears to work fine, as I tested with CMake 2.8.12.2 (for
both Visual C++ 2008 and Visual C++ 2013):
get_filename_component(MY_COMPILER_DIR
${CMAKE_CXX_COMPILER} DIRECTORY)
find_file(MY_VCVARSALL_BAT vcvarsall
12 matches
Mail list logo
