Brad King wrote:
> On 10/30/2013 12:12 PM, Stephen Kelly wrote:
>> Stephen Kelly wrote:
>>> I think there is a bug here.
>
> Behavior is as documented so it is at most a missing feature.
That reminds me - CMAKE_OSX_SYSROOT is not documented at all.
> Why do you need NO_DEFAULT_PATH when looking
On 10/30/2013 12:12 PM, Stephen Kelly wrote:
> Stephen Kelly wrote:
>> I think there is a bug here.
Behavior is as documented so it is at most a missing feature.
Why do you need NO_DEFAULT_PATH when looking for GL libraries?
You're looking for a system-provided library so why tell CMake not
to se
Stephen Kelly wrote:
> Brad King wrote:
>
>> These folks should try the CMake 2.8.12 release. It added these:
>>
>> OS X: Search system SDKs for frameworks
>> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1fce189e
>>
>> OS X: Enable command-line build without tools in PATH
>> http://cmake
Brad King wrote:
> On 10/30/2013 10:39 AM, Stephen Kelly wrote:
>> Makes sense to me.
>>
>> COMPILER_FEATURES -> COMPILE_FEATURES
>> INTERFACE_COMPILER_FEATURES -> INTERFACE_COMPILE_FEATURES
>
> Yes, matching COMPILE_OPTIONS and COMPILE_DEFINITIONS.
Right, done now.
Thanks,
Steve.
--
Pow
On 10/30/2013 10:39 AM, Stephen Kelly wrote:
> Makes sense to me.
>
> COMPILER_FEATURES -> COMPILE_FEATURES
> INTERFACE_COMPILER_FEATURES -> INTERFACE_COMPILE_FEATURES
Yes, matching COMPILE_OPTIONS and COMPILE_DEFINITIONS.
Thanks,
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-
On 10/30/2013 10:30 AM, Stephen Kelly wrote:
> Ok. I've updated my topic to remove the policy logic.
Thanks. Some comments:
+ onlyPlain = false;
+ break;
Can't that just be "return false" now?
Also please add the corresponding test case and base the topic
on v2.8.12~2 so we c
Brad King wrote:
> Steve,
>
> On 10/25/2013 09:11 AM, Brad King wrote:
>> Yes, I think that makes sense.
>
> Looking at the documentation generated in 'next' I see this
> list of commands:
>
> target_compile_definitions
> target_compile_options
> target_compiler_features
>
> I think the new
Brad King wrote:
> On 10/30/2013 09:01 AM, Stephen Kelly wrote:
>> Brad King wrote:
>>
>>> When CMP0022 is NEW the INTERFACE_LINK_LIBRARIES is always the link
>>> interface without the link implementation fallback, but the tll plain
>>> signature does not populate INTERFACE_LINK_LIBRARIES either.
Steve,
On 10/25/2013 09:11 AM, Brad King wrote:
> Yes, I think that makes sense.
Looking at the documentation generated in 'next' I see this
list of commands:
target_compile_definitions
target_compile_options
target_compiler_features
I think the new command should be called
target_compile_
Brad King wrote:
> These folks should try the CMake 2.8.12 release. It added these:
>
> OS X: Search system SDKs for frameworks
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1fce189e
>
> OS X: Enable command-line build without tools in PATH
> http://cmake.org/gitweb?p=cmake.git;a=commitd
On 10/30/2013 09:01 AM, Stephen Kelly wrote:
> Brad King wrote:
>
>> When CMP0022 is NEW the INTERFACE_LINK_LIBRARIES is always the link
>> interface without the link implementation fallback, but the tll plain
>> signature does not populate INTERFACE_LINK_LIBRARIES either. This is
>> not correct.
Brad King wrote:
> When CMP0022 is NEW the INTERFACE_LINK_LIBRARIES is always the link
> interface without the link implementation fallback, but the tll plain
> signature does not populate INTERFACE_LINK_LIBRARIES either. This is
> not correct.
I actually prefer this behavior, but as it's not ba
12 matches
Mail list logo
