The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14281
==
Reported By:nomorgan
Assigned To:
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14280
==
Reported By:Daniel Franke
Assigned To:
2013/7/8 Brad King :
> On 7/3/2013 5:10 PM, Vadim Zhukov wrote:
>> 2. Just make sure BACKTRACE_LIBRARIES is empty: if the developer wants
>> to shoot himself in the foot with -nostdlib, then he's responsible
>
> Yes, I agree with this approach. However,
>
> cmake_push_check_state()
>
> will not e
2013/7/8 Alexander Neundorf :
> On Friday 05 July 2013, Eric Noulard wrote:
>> > I don't think an inappropriate amount of work or fundamental change to
>> > cmake is required to achieve step 2.
>>
>> "innappropriate amount" heavily depends on who is doing the job but I guess
>> that the already pro
Brad King wrote:
> On 7/8/2013 3:58 PM, Stephen Kelly wrote:
>> Yesterday I made a commit to set CMAKE_LEGACY_CYGWIN_WIN32 as suggested,
>> but it did not silence the warning. I don't know where the warning comes
>> from.
>
> The first project() call is in
>
> Tests/RunCMake/CMP0022/CMakeLists.
On 7/8/2013 3:58 PM, Stephen Kelly wrote:
> Yesterday I made a commit to set CMAKE_LEGACY_CYGWIN_WIN32 as suggested, but
> it did not silence the warning. I don't know where the warning comes from.
The first project() call is in
Tests/RunCMake/CMP0022/CMakeLists.txt
so this needs to be set bef
One of the dashboards is failing currently on this branch:
http://open.cdash.org/testDetails.php?test=197185916&build=2959788
The problem is that the test expects an empty stderr because the policy
warning is expected not to be issued.
However, another warning is issued:
actual-err> CMake
On Friday 05 July 2013, Eric Noulard wrote:
> > I don't think an inappropriate amount of work or fundamental change to
> > cmake is required to achieve step 2.
>
> "innappropriate amount" heavily depends on who is doing the job but I guess
> that the already proven workload given by Stephen to CMa
On 7/4/2013 4:29 AM, Stephen Kelly wrote:
> I can't think of anything that can be done with CMAKE_FIND_ROOT_PATH which
> can't be done with CMAKE_PREFIX_PATH (with a bit more repetition on the
> command line, I think). Should we enumerate the use cases to consider
> documenting it obsolete?
One
On 7/8/2013 11:57 AM, Stephen Kelly wrote:
> You mean a case like installing to
> /opt/kf5-cross
> where
> /opt/kf5-cross/lib -> /opt/kf5-cross/usr/lib
> and where we install /opt/kf5-cross/usr/lib/cmake/KArchive.cmake ?
Yes.
> I think the cmake code generated in that method would have to als
Brad King wrote:
> On 7/8/2013 11:22 AM, Stephen Kelly wrote:
>> Brad King wrote:
>>> or do you mean that CMAKE_HOST_INSTALL_PREFIX, if defined at all,
>>> completely replaces CMAKE_INSTALL_PREFIX for all install rules?
>>
>> Yes for install rules, but with some exceptions I think when used in
>>
On 7/8/2013 11:22 AM, Stephen Kelly wrote:
> Brad King wrote:
>> or do you mean that CMAKE_HOST_INSTALL_PREFIX, if defined at all,
>> completely replaces CMAKE_INSTALL_PREFIX for all install rules?
>
> Yes for install rules, but with some exceptions I think when used in
> calculations.
>
> For t
Brad King wrote:
> On 7/8/2013 9:31 AM, Brad King wrote:
>> Yes, but how does install() know that "foo" is for the host
>> or the target?
>
> or do you mean that CMAKE_HOST_INSTALL_PREFIX, if defined at all,
> completely replaces CMAKE_INSTALL_PREFIX for all install rules?
Yes for install rules,
Brad King wrote:
> On 7/8/2013 9:06 AM, Stephen Kelly wrote:
>> I was thinking of cases where the install DESTINATION is relative:
>>
>> install(TARGETS foo ... DESTINATION lib)
>>
>> If CMAKE_HOST_INSTALL_PREFIX is defined, foo is installed to
>>
>> ${CMAKE_HOST_INSTALL_PREFIX}/lib
>>
>> ot
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14279
==
Reported By:dbcfd
Assigned To:
=
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14278
==
Reported By:dbcfd
Assigned To:
=
On 7/3/2013 5:10 PM, Vadim Zhukov wrote:
> 2. Just make sure BACKTRACE_LIBRARIES is empty: if the developer wants
> to shoot himself in the foot with -nostdlib, then he's responsible
Yes, I agree with this approach. However,
cmake_push_check_state()
will not erase any existing CMAKE_REQUIRED_*
On 7/8/2013 9:31 AM, Brad King wrote:
> Yes, but how does install() know that "foo" is for the host
> or the target?
or do you mean that CMAKE_HOST_INSTALL_PREFIX, if defined at all,
completely replaces CMAKE_INSTALL_PREFIX for all install rules?
-Brad
--
Powered by www.kitware.com
Visit other
On 7/8/2013 9:06 AM, Stephen Kelly wrote:
> I was thinking of cases where the install DESTINATION is relative:
>
> install(TARGETS foo ... DESTINATION lib)
>
> If CMAKE_HOST_INSTALL_PREFIX is defined, foo is installed to
>
> ${CMAKE_HOST_INSTALL_PREFIX}/lib
>
> otherwise
>
> ${CMAKE_INSTA
Brad King wrote:
> On 07/04/2013 04:29 AM, Stephen Kelly wrote:
>>> How do install() invocations distinguish which prefix to use?
>>
>> I think install invokations use CMAKE_HOST_INSTALL_PREFIX for everything
>> if present, and CMAKE_INSTALL_PREFIX otherwise.
>
> Before I answer the rest of the
On 07/04/2013 04:29 AM, Stephen Kelly wrote:
>> How do install() invocations distinguish which prefix to use?
>
> I think install invokations use CMAKE_HOST_INSTALL_PREFIX for everything if
> present, and CMAKE_INSTALL_PREFIX otherwise.
Before I answer the rest of the message I'd like clarificat
21 matches
Mail list logo
