Stephen Kelly wrote:
>
> Ok, knowing why it fails on APPLE is good enough for me for now.
>
> The tests can be enabled on APPLE again later, I've flipped the if
> condition so we can see why it fails on some non-APPLE platforms too.
>
I was given access to a freebsd box to see why the build su
Stephen Kelly wrote:
>
> Ok, knowing why it fails on APPLE is good enough for me for now.
>
> The tests can be enabled on APPLE again later, I've flipped the if
> condition so we can see why it fails on some non-APPLE platforms too.
>
I was given access to a freebsd box to see why the build su
Am Donnerstag, 13. Oktober 2011, 18:00:23 schrieb Rolf Eike Beer:
> > Rolf Eike Beer wrote:
> >>> I'm not certain that's correct though. Those flags don't seem to be
> >>> used
> >>> when I build. I also don't know what those flags do.
> >>>
> >>> Linking CXX executable exec
> >>> /home/stephen/de
Rolf Eike Beer wrote:
>> Rolf Eike Beer wrote:
>>
I'm not certain that's correct though. Those flags don't seem to be
used
when I build. I also don't know what those flags do.
Linking CXX executable exec
/home/stephen/dev/qt48/kde/bin/cmake -E cmake_link_script
C
On Thu, Oct 13, 2011 at 12:01 PM, Stephen Kelly wrote:
> On Thu, Oct 13, 2011 at 4:33 PM, Richard Wackerbarth
> wrote:
>> Steve,
>>
>> Here is the output from the version of test19 that you sent privately.
>> The version of cmake was built with last night's dashboard.
>> I don't see the failure
On Thu, Oct 13, 2011 at 4:33 PM, Richard Wackerbarth wrote:
> Steve,
>
> Here is the output from the version of test19 that you sent privately.
> The version of cmake was built with last night's dashboard.
> I don't see the failure here. Am I doing something wrong?
Hi,
it doesn't look like you'r
> Rolf Eike Beer wrote:
>
>>> I'm not certain that's correct though. Those flags don't seem to be
>>> used
>>> when I build. I also don't know what those flags do.
>>>
>>> Linking CXX executable exec
>>> /home/stephen/dev/qt48/kde/bin/cmake -E cmake_link_script
>>> CMakeFiles/exec.dir/link.txt --ve
Rolf Eike Beer wrote:
>> I'm not certain that's correct though. Those flags don't seem to be used
>> when I build. I also don't know what those flags do.
>>
>> Linking CXX executable exec
>> /home/stephen/dev/qt48/kde/bin/cmake -E cmake_link_script
>> CMakeFiles/exec.dir/link.txt --verbose=1
>> /u
> Rolf Eike Beer wrote:
>
Stephen Kelly wrote:
> The tests can be enabled on APPLE again later, I've flipped the if
> condition so we can see why it fails on some non-APPLE platforms too.
>
This is even more interesting now.
http://www.cdash.org/CDash/testD
Rolf Eike Beer wrote:
>>> Stephen Kelly wrote:
>>>
The tests can be enabled on APPLE again later, I've flipped the if
condition so we can see why it fails on some non-APPLE platforms too.
>>>
>>> This is even more interesting now.
>>>
>>> http://www.cdash.org/CDash/testDetails.php?t
>> Stephen Kelly wrote:
>>
>>> The tests can be enabled on APPLE again later, I've flipped the if
>>> condition so we can see why it fails on some non-APPLE platforms too.
>>>
>>
>> This is even more interesting now.
>>
>> http://www.cdash.org/CDash/testDetails.php?test=118872016&build=1620094
>>
>
> Stephen Kelly wrote:
>
>> The tests can be enabled on APPLE again later, I've flipped the if
>> condition so we can see why it fails on some non-APPLE platforms too.
>>
>
> This is even more interesting now.
>
> http://www.cdash.org/CDash/testDetails.php?test=118872016&build=1620094
>
> On gentoo
> Stephen Kelly wrote:
>
>> The tests can be enabled on APPLE again later, I've flipped the if
>> condition so we can see why it fails on some non-APPLE platforms too.
>
> This is even more interesting now.
>
> http://www.cdash.org/CDash/testDetails.php?test=118872016&build=1620094
>
> On gentoo, t
Stephen Kelly wrote:
> The tests can be enabled on APPLE again later, I've flipped the if
> condition so we can see why it fails on some non-APPLE platforms too.
>
This is even more interesting now.
http://www.cdash.org/CDash/testDetails.php?test=118872016&build=1620094
On gentoo, the build of
On 10/12/2011 06:37 PM, Richard Wackerbarth wrote:
Given the question about "other platforms", I did an update to next
on my newest FreeBSD build machine.
New revision of repository is: f48a0be07ebcdbe5d6c6a10d34e70cce164d9a9b
Bad news:
Start 147: CMakeCommands.target_link_librari
On 10/12/2011 10:38 AM, David Cole wrote:
On Wed, Oct 12, 2011 at 10:30 AM, Stephen Kelly wrote:
I already grepped for CMAKE_LINK_DEPENDENT_LIBRARY_FILES and it seems to not
appear anywhere else but Darwin.cmake. I remember the tests failing on
freebsd and some windows too, so if you have any i
On Wed, Oct 12, 2011 at 10:30 AM, Stephen Kelly wrote:
> Brad King wrote:
>
>> On 10/12/2011 2:22 AM, Stephen Kelly wrote:
>>> using set(CMAKE_LINK_INTERFACE_LIBRARIES "") should be the same as using
>>>
>>> target_link_libraries(libA LINK_INTERFACE_LIBRARIES "")
>>>
>>> for each library.
>>
>> It
Brad King wrote:
> On 10/12/2011 2:22 AM, Stephen Kelly wrote:
>> using set(CMAKE_LINK_INTERFACE_LIBRARIES "") should be the same as using
>>
>> target_link_libraries(libA LINK_INTERFACE_LIBRARIES "")
>>
>> for each library.
>
> It is. The example under discussion has the same behavior even if y
On 10/12/2011 2:22 AM, Stephen Kelly wrote:
using set(CMAKE_LINK_INTERFACE_LIBRARIES "") should be the same as using
target_link_libraries(libA LINK_INTERFACE_LIBRARIES "")
for each library.
It is. The example under discussion has the same behavior even if you
explicitly set it on each targe
Bill Hoffman wrote:
> So, basically we this:
>
>
> set(CMAKE_LINK_INTERFACE_LIBRARIES "")
>
> add_library(libA SHARED classA.cpp)
> add_library(libB SHARED classB.cpp)
> add_library(libC SHARED classC.cpp)
>
> generate_export_header(libA)
> generate_export_header(libB)
> generate_export_header
So, basically we this:
set(CMAKE_LINK_INTERFACE_LIBRARIES "")
add_library(libA SHARED classA.cpp)
add_library(libB SHARED classB.cpp)
add_library(libC SHARED classC.cpp)
generate_export_header(libA)
generate_export_header(libB)
generate_export_header(libC)
target_link_libraries(libB libA)
tar
I am running your test right now...
I do get these warnings:
CMake Warning at
/Users/kitware/bill/cmake/Modules/GenerateExportHeader.cmake:178 (message):
GCC version older than 4.2
Call Stack (most recent call first):
/Users/kitware/bill/cmake/Modules/GenerateExportHeader.cmake:348
(_tes
Bill Hoffman wrote:
> On 10/11/2011 2:33 AM, Stephen Kelly wrote:
>>
>> Hi,
>>
>> I'm trying to find out why the target_link_libraries unit tests are
>> failing on some platforms (but not mine...). I'm enabling one platform at
>> a time. I enabled the failing tests for APPLE, so if you want to try
On 10/11/2011 2:33 AM, Stephen Kelly wrote:
Hi,
I'm trying to find out why the target_link_libraries unit tests are failing
on some platforms (but not mine...). I'm enabling one platform at a time. I
enabled the failing tests for APPLE, so if you want to try it out, you need
to comment out the
Hi,
I'm trying to find out why the target_link_libraries unit tests are failing
on some platforms (but not mine...). I'm enabling one platform at a time. I
enabled the failing tests for APPLE, so if you want to try it out, you need
to comment out the if(APPLE).
http://www.cdash.org/CDash/test
25 matches
Mail list logo
