On 2013-03-13 20:59, Matthew Woehlke wrote:
This simple CMakeLists.txt is broken with ninja:
cmake_minimum_required(VERSION 2.8.10.20130312)
project(Foo)
add_executable(foo foo.cpp)
target_include_directories(foo PUBLIC
$
$
)
...with Ninja, the include directive passed to the compiler i
r_b_d != rbd
Therefore, ${r_b_d} is the empty string.
From: Matthew Woehlke
Sent: March 13, 2013 8:51 PM
To: cmake-developers@cmake.org
Subject: [cmake-developers] bizarre g_f_c(REALPATH) bug; works backwards(?!)
I've discovered an odd an seemingly incorrect behavior of
get_fi
On 2013-03-13 20:59, Matthew Woehlke wrote:
This simple CMakeLists.txt is broken with ninja:
cmake_minimum_required(VERSION 2.8.10.20130312)
project(Foo)
add_executable(foo foo.cpp)
target_include_directories(foo PUBLIC
$
$
)
...with Ninja, the include directive passed to the compiler i
This simple CMakeLists.txt is broken with ninja:
cmake_minimum_required(VERSION 2.8.10.20130312)
project(Foo)
add_executable(foo foo.cpp)
target_include_directories(foo PUBLIC
$
$
)
...with Ninja, the include directive passed to the compiler is '-I.'
(with the binary dir prefix similarly
I've discovered an odd an seemingly incorrect behavior of
get_filename_component(REALPATH)... apparently there are some conditions
when it can take a canonical path and turn it *back into a symlink*.
To reproduce:
$ ls -l
lrwxrwxrwx. 1 matthew matthew 10 Mar 13 20:17 build -> real-build
drwx
On Wednesday 13 March 2013, Stephen Kelly wrote:
> Brad King wrote:
...
> > Can you and Alex agree that fix-automoc-no-qt is sufficient for
> > the upcoming release?
>
> I agree that it is sufficient.
>
> I think Alex' objection is only related to thinking that the case of a
> header-only-library
Brad King wrote:
> On 03/13/2013 02:09 PM, Stephen Kelly wrote:
>>> If I turn it on, it works. So it seems as though something is not fully
>>> respecting BUILD_TESTING?
>>
>> git-bisect tells me
>> e03f83f394c53acbcc9dcff03f189170b2f33322 is the culprit (ProcessorCount
>> test: fix path to cmsys
On 03/13/2013 02:09 PM, Stephen Kelly wrote:
>> If I turn it on, it works. So it seems as though something is not fully
>> respecting BUILD_TESTING?
>
> git-bisect tells me
> e03f83f394c53acbcc9dcff03f189170b2f33322 is the culprit (ProcessorCount
> test: fix path to cmsysTestsCxx executable, 201
Matthew Woehlke wrote:
> If I turn off BUILD_TESTING, I get this error:
>
>
> CMake Error at Tests/CMakeTests/CMakeLists.txt:7 (add_test):
> Error evaluating generator expression:
>
> $
>
> No target "cmsysTestsCxx"
> Call Stack (most recent call first):
> Tests/CMakeTest
If I turn off BUILD_TESTING, I get this error:
CMake Error at Tests/CMakeTests/CMakeLists.txt:7 (add_test):
Error evaluating generator expression:
$
No target "cmsysTestsCxx"
Call Stack (most recent call first):
Tests/CMakeTests/CMakeLists.txt:32 (AddCMakeTest)
If I turn it o
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14010
==
Reported By:Kevin Burge
Assigned To:
Brad King wrote:
> On 03/12/2013 06:30 PM, Brad King wrote:
>> On 03/12/2013 06:08 PM, Alexander Neundorf wrote:
>>> My AutomocFixWithoutQt branch basically reverts the first commit, so
>>> automoc is now again only one step, without the temporary vector of
>>> targets, without needing additional
On 03/12/2013 06:30 PM, Brad King wrote:
> On 03/12/2013 06:08 PM, Alexander Neundorf wrote:
>> My AutomocFixWithoutQt branch basically reverts the first commit, so automoc
>> is now again only one step, without the temporary vector of targets, without
>> needing additional checks. In this form t
The following issue has been SUBMITTED.
==
http://www.itk.org/Bug/view.php?id=14009
==
Reported By:Braden McDaniel
Assigned To:
On 03/13/2013 04:37 AM, m.hergarden wrote:
> The following commit:
> 21123416b4c2d49fe981279b10fbc78c8d07c491
>
> Introduced this line:
> Modules/FindQt4.cmake line 564:
>
> set(${QMAKE_RESULT} "${QT_QMAKE_QMAKE_EXECUTABLE}" PARENT_SCOPE)
>
> The variable QT_QMAKE_QMAKE_EXECUTABLE is never used
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14008
==
Reported By:Magnus
Assigned To:
The following commit:
21123416b4c2d49fe981279b10fbc78c8d07c491
Introduced this line:
Modules/FindQt4.cmake line 564:
set(${QMAKE_RESULT} "${QT_QMAKE_QMAKE_EXECUTABLE}" PARENT_SCOPE)
The variable QT_QMAKE_QMAKE_EXECUTABLE is never used however and I
suspect that it should be QT_QMAKE_EXECUTABLE.
Brad King wrote:
> Lots of generation APIs exit early and tolerate missing info.
> Without C++ exceptions and proper RAII we will not be able to
> have a general solution.
Yes.
What I'd like to see, if possible, is ensuring that a completely invalid
buildsystem is created if a generate-time err
Brad King wrote:
> On 03/11/2013 07:01 PM, Stephen Kelly wrote:
>> Stephen Kelly wrote:
>>> Alexander Neundorf wrote:
The patch only avoided that specific situation when it occured with
automoc, but the same situation can also happen independent from
automoc.
>>>
>>> Not really, the
19 matches
Mail list logo
