Re: [cmake-developers] Importing platform SDK libraries without a full path

On 10/06/2015 11:30 AM, Brad King wrote: > On 10/04/2015 10:49 AM, Stephen Kelly wrote: >> I wonder if you plan do resolve this part in the coming cycle? I think >> resolving that part would help me to understand the rest of your proposal in >> the thread. > > I don't know if/when I'll ever have

Re: [cmake-developers] Importing platform SDK libraries without a full path

Brad King writes: > >> Actually I think this can and should be done for INTERFACE libraries > >> even without IMPORTED_LIBNAME. I'll look at factoring this part out > >> into a preceding commit. > > > > Cool, I think reviewing that separately would be preferable. > > > > I'm

Re: [cmake-developers] Importing platform SDK libraries without a full path

On 05/27/2015 05:58 PM, Stephen Kelly wrote: I see INTERFACE as has no location (lower case), and I see IMPORTED_LIBNAME as a location. It specifies to the toolchain-supplied compiler to locate a particular toolchain-supplied library and link it. I define location as known full path to a

Re: [cmake-developers] Importing platform SDK libraries without a full path

On 05/26/2015 05:14 PM, Stephen Kelly wrote: This would amount to a separate task of making IMPORTED_LOCATION an error on an INTERFACE library. Actually this is already an error case because IMPORTED_LOCATION is not whitelisted, so nothing more to do. Great. + property value\n

Re: [cmake-developers] Importing platform SDK libraries without a full path

Brad King wrote: It seems that the meaning of INTERFACE libraries is being overloaded with the opposite of their meaning. The meaning of INTERFACE is that it specifies usage requirements without itself building anything. In this, it is the same as IMPORTED libraries. A key distinction is

Re: [cmake-developers] Importing platform SDK libraries without a full path

On 05/27/2015 02:40 PM, Stephen Kelly wrote: By current 'design language' it is not a 'usage requirement', just like IMPORTED_LOCATION, LOCATION, $TARGET_FILE and others are not 'usage requirements'. Sure, but it does tell CMake what to do when a client consumes the interface. I still

Re: [cmake-developers] Importing platform SDK libraries without a full path

Brad King wrote: On 05/27/2015 02:40 PM, Stephen Kelly wrote: By current 'design language' it is not a 'usage requirement', just like IMPORTED_LOCATION, LOCATION, $TARGET_FILE and others are not 'usage requirements'. Sure, but it does tell CMake what to do when a client consumes the

Re: [cmake-developers] Importing platform SDK libraries without a full path

On 05/25/2015 08:27 AM, Stephen Kelly wrote: it should probably be an error to use TARGET_FILE on an INTERFACE target. That doesn't seem to currently be the case. We already reject that. I've added a test case to show this in another topic: Tests: Add case for rejecting $TARGET_FILE:... on

Re: [cmake-developers] Importing platform SDK libraries without a full path

Brad King wrote: On 05/25/2015 08:27 AM, Stephen Kelly wrote: it should probably be an error to use TARGET_FILE on an INTERFACE target. That doesn't seem to currently be the case. We already reject that. I've added a test case to show this in another topic: Tests: Add case for

Re: [cmake-developers] Importing platform SDK libraries without a full path

Brad King wrote: We cannot lift the requirement that IMPORTED_LOCATION be a full path because that is fundamental to the design of imported targets and is needed for things like $TARGET_FILE:... to work correctly. Could you add a unit test showing what happens when using that genex with a