Re: [cmake-developers] Allow ALIAS of IMPORTED targets

2015-09-18 Thread Andreas Schuh 
Hi,

Being able to alias imported targets would be a great feature. Just an
addition to the exports discussion, I also don't think it is necessary.
Besides the EXPORT_NAME property I was not aware of either, I would instead
expect to see an

  add_library (old_name ALIAS new_name)

in the ProjectConfig.cmake(.in) file after importing the new_name library
target. This would make it more clear that it is just an alias for the
actual new exported/imported target. Also no need to maintain copies of
identical imported target properties. I would find this more appealing than
exporting the same target twice but with different name. I would think this
was just done before because of the missing ability to alias an imported
target.

Andreas
On 15 Sep 2015 21:36, "Tamás Kenéz"  wrote:

> Thank you, I was not aware of the EXPORT_NAME target property.
> Tamas
>
> On Tue, Sep 15, 2015 at 7:36 PM, Stephen Kelly  wrote:
>
>> Tamás Kenéz wrote:
>>
>> >> For example, if an ALIAS can be IMPORTED, does it makes sense that it
>> can
>> > be
>> >> exported with export() and install(EXPORT)?
>> >
>> > Yes: couple of months ago I was adding install(EXPORT) to an existing
>> > CMakeList. The name of the library target which I had to export was not
>> > correct as export target name but I was not able change the library
>> target
>> > name because of backward compatibility. Being able to export an alias
>> > would have helped.
>>
>> I still think exporting should be a follow up to allowing IMPORTED ALIAS.
>> Just too keep the branch and discussion as short as possible.
>>
>> Nevertheless, I think you wouldn't need ALIAS targets for your use-case.
>> They are more than you need. You don't need the aliases anywhere except
>> for
>> exporting. So, we could design something which allows you to export
>> aliases,
>> but be completely separate from ALIAS targets.
>>
>> For example,
>>
>>  add_library(foo ${foo_SRCS})
>>  set_target_property(foo EXPORT_NAMES foo foo_old_name)
>>
>>  ...
>>
>>  install(EXPORT ...)
>>
>> resulting in a generated file containing
>>
>>  add_library(foo IMPORTED)
>>  ...
>>
>>  add_library(foo_old_name IMPORTED)
>>  ...
>>
>> where each of the generated targets get the same target properties.
>>
>> Note that there is already an EXPORT_NAME target property
>>
>>  http://www.cmake.org/cmake/help/v3.3/prop_tgt/EXPORT_NAME.html
>>
>> but it is not a list, so the task would probably be to deprecate that one
>> and add EXPORT_NAMES.
>>
>> I filed
>>
>>  http://public.kitware.com/Bug/view.php?id=15745
>>
>> Thanks,
>>
>> Steve.
>>
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake-developers
>>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Allow ALIAS of IMPORTED targets

2015-09-15 Thread CHEVRIER, Marc 

I completely agree. Seems reasonable to disallow exporting ALIAS targets.

Marc




On 14/09/15 19:34, "cmake-developers on behalf of Stephen Kelly" 
 wrote:

>Michael Scott wrote:
>
>> Hi,
>> 
>> I'm planning on having a look at the CMake issue "Allow ALIAS of
>> IMPORTED targets", 0015569. After reading the thread between yourself
>> and Marc, I wanted to ask a couple of things before I start going
>> further with it.
>
>Thanks for working on this.
>
>> The proposed change would be for the add_library and add_executable
>> commands only right?
>
>Yes, I guess so.
>
>> Having a quick look at the code for those two commands, they
>> specifically check for a combination of ALIAS and IMPORTED and don't
>> allow it. I'm guessing that the required changes to allow both
>> simultaneously wouldn't be to just remove this check, there would be
>> other areas to modify as well right?
>
>Perhaps. Finding that out is the real task :). I don't have all the answers 
>to it. The specific disallowing of ALIAS and IMPORTED together by issuing an 
>error was a way to defer finding those answers while not being required to 
>maintain compatibility with a particular behavior. I didn't want finding 
>those answers to delay getting the ALIAS feature in, because it was useful 
>already as it was.
>
>Now, we have time to consider all of the implications of allowing this as 
>part of the design.
>
>For example, if an ALIAS can be IMPORTED, does it makes sense that it can be 
>exported with export() and install(EXPORT)?
>
>If we have 
>
> add_library(CoreStatic ${Core_SRCS})
> add_library(MyNS::Core ALIAS CoreStatic)
>
>and I export both of them with the NAMESPACE 'MyNS::', do I end up with 
>
> MyNS::MyNS::Core 
>
>?
>
>Or would the exporting code strip of everything before a '::' in the alias 
>name?
>
>Or should exporting ALIAS targets still be disallowed?
>
>The two use cases described in 
> 
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/52452
>
>seem like they would not benefit from exporting ALIAS targets.
>
>A reasonable way forward might be:
>
>* Keep the restriction that ALIAS targets may not be exported.
>* Remove the code disallowing ALIAS IMPORTED targets.
>* Remove the unit test proving it is not allowed
>* Add new unit tests that it basically works
>* Add a unit test for using an ALIAS with try_compile(LINK_LIBRARIES)
>* (Anything else that comes up along the way)
>
>Thanks,
>
>Steve.
>
>
>-- 
>
>Powered by www.kitware.com
>
>Please keep messages on-topic and check the CMake FAQ at: 
>http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For more 
>information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>Visit other Kitware open-source projects at 
>http://www.kitware.com/opensource/opensource.html
>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Allow ALIAS of IMPORTED targets

2015-09-15 Thread Stephen Kelly 
Tamás Kenéz wrote:

>> For example, if an ALIAS can be IMPORTED, does it makes sense that it can
> be
>> exported with export() and install(EXPORT)?
> 
> Yes: couple of months ago I was adding install(EXPORT) to an existing
> CMakeList. The name of the library target which I had to export was not
> correct as export target name but I was not able change the library target
> name because of backward compatibility. Being able to export an alias
> would have helped.

I still think exporting should be a follow up to allowing IMPORTED ALIAS. 
Just too keep the branch and discussion as short as possible.

Nevertheless, I think you wouldn't need ALIAS targets for your use-case. 
They are more than you need. You don't need the aliases anywhere except for 
exporting. So, we could design something which allows you to export aliases, 
but be completely separate from ALIAS targets.

For example,

 add_library(foo ${foo_SRCS})
 set_target_property(foo EXPORT_NAMES foo foo_old_name)
 
 ...

 install(EXPORT ...)

resulting in a generated file containing

 add_library(foo IMPORTED)
 ...

 add_library(foo_old_name IMPORTED)
 ...

where each of the generated targets get the same target properties.

Note that there is already an EXPORT_NAME target property

 http://www.cmake.org/cmake/help/v3.3/prop_tgt/EXPORT_NAME.html

but it is not a list, so the task would probably be to deprecate that one 
and add EXPORT_NAMES.

I filed

 http://public.kitware.com/Bug/view.php?id=15745

Thanks,

Steve.



-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Allow ALIAS of IMPORTED targets

2015-09-15 Thread Tamás Kenéz 
Thank you, I was not aware of the EXPORT_NAME target property.
Tamas

On Tue, Sep 15, 2015 at 7:36 PM, Stephen Kelly  wrote:

> Tamás Kenéz wrote:
>
> >> For example, if an ALIAS can be IMPORTED, does it makes sense that it
> can
> > be
> >> exported with export() and install(EXPORT)?
> >
> > Yes: couple of months ago I was adding install(EXPORT) to an existing
> > CMakeList. The name of the library target which I had to export was not
> > correct as export target name but I was not able change the library
> target
> > name because of backward compatibility. Being able to export an alias
> > would have helped.
>
> I still think exporting should be a follow up to allowing IMPORTED ALIAS.
> Just too keep the branch and discussion as short as possible.
>
> Nevertheless, I think you wouldn't need ALIAS targets for your use-case.
> They are more than you need. You don't need the aliases anywhere except for
> exporting. So, we could design something which allows you to export
> aliases,
> but be completely separate from ALIAS targets.
>
> For example,
>
>  add_library(foo ${foo_SRCS})
>  set_target_property(foo EXPORT_NAMES foo foo_old_name)
>
>  ...
>
>  install(EXPORT ...)
>
> resulting in a generated file containing
>
>  add_library(foo IMPORTED)
>  ...
>
>  add_library(foo_old_name IMPORTED)
>  ...
>
> where each of the generated targets get the same target properties.
>
> Note that there is already an EXPORT_NAME target property
>
>  http://www.cmake.org/cmake/help/v3.3/prop_tgt/EXPORT_NAME.html
>
> but it is not a list, so the task would probably be to deprecate that one
> and add EXPORT_NAMES.
>
> I filed
>
>  http://public.kitware.com/Bug/view.php?id=15745
>
> Thanks,
>
> Steve.
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Allow ALIAS of IMPORTED targets

2015-09-14 Thread Stephen Kelly 
Michael Scott wrote:

> Hi,
> 
> I'm planning on having a look at the CMake issue "Allow ALIAS of
> IMPORTED targets", 0015569. After reading the thread between yourself
> and Marc, I wanted to ask a couple of things before I start going
> further with it.

Thanks for working on this.

> The proposed change would be for the add_library and add_executable
> commands only right?

Yes, I guess so.

> Having a quick look at the code for those two commands, they
> specifically check for a combination of ALIAS and IMPORTED and don't
> allow it. I'm guessing that the required changes to allow both
> simultaneously wouldn't be to just remove this check, there would be
> other areas to modify as well right?

Perhaps. Finding that out is the real task :). I don't have all the answers 
to it. The specific disallowing of ALIAS and IMPORTED together by issuing an 
error was a way to defer finding those answers while not being required to 
maintain compatibility with a particular behavior. I didn't want finding 
those answers to delay getting the ALIAS feature in, because it was useful 
already as it was.

Now, we have time to consider all of the implications of allowing this as 
part of the design.

For example, if an ALIAS can be IMPORTED, does it makes sense that it can be 
exported with export() and install(EXPORT)?

If we have 

 add_library(CoreStatic ${Core_SRCS})
 add_library(MyNS::Core ALIAS CoreStatic)

and I export both of them with the NAMESPACE 'MyNS::', do I end up with 

 MyNS::MyNS::Core 

?

Or would the exporting code strip of everything before a '::' in the alias 
name?

Or should exporting ALIAS targets still be disallowed?

The two use cases described in 
 
 http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/52452

seem like they would not benefit from exporting ALIAS targets.

A reasonable way forward might be:

* Keep the restriction that ALIAS targets may not be exported.
* Remove the code disallowing ALIAS IMPORTED targets.
* Remove the unit test proving it is not allowed
* Add new unit tests that it basically works
* Add a unit test for using an ALIAS with try_compile(LINK_LIBRARIES)
* (Anything else that comes up along the way)

Thanks,

Steve.


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Allow ALIAS of IMPORTED targets

2015-09-14 Thread Tamás Kenéz 
> For example, if an ALIAS can be IMPORTED, does it makes sense that it can
be
> exported with export() and install(EXPORT)?

Yes: couple of months ago I was adding install(EXPORT) to an existing
CMakeList. The name of the library target which I had to export was not
correct as export target name but I was not able change the library target
name because of backward compatibility. Being able to export an alias would
have helped.

> and I export both of them with the NAMESPACE 'MyNS::', do I end up with
> MyNS::MyNS::Core

I guess so, at least that's what I would expect. As far as I know the
install(EXPORT) blindly preprends the target name with the namespace string.

Tamas

On Mon, Sep 14, 2015 at 7:34 PM, Stephen Kelly  wrote:

> Michael Scott wrote:
>
> > Hi,
> >
> > I'm planning on having a look at the CMake issue "Allow ALIAS of
> > IMPORTED targets", 0015569. After reading the thread between yourself
> > and Marc, I wanted to ask a couple of things before I start going
> > further with it.
>
> Thanks for working on this.
>
> > The proposed change would be for the add_library and add_executable
> > commands only right?
>
> Yes, I guess so.
>
> > Having a quick look at the code for those two commands, they
> > specifically check for a combination of ALIAS and IMPORTED and don't
> > allow it. I'm guessing that the required changes to allow both
> > simultaneously wouldn't be to just remove this check, there would be
> > other areas to modify as well right?
>
> Perhaps. Finding that out is the real task :). I don't have all the answers
> to it. The specific disallowing of ALIAS and IMPORTED together by issuing
> an
> error was a way to defer finding those answers while not being required to
> maintain compatibility with a particular behavior. I didn't want finding
> those answers to delay getting the ALIAS feature in, because it was useful
> already as it was.
>
> Now, we have time to consider all of the implications of allowing this as
> part of the design.
>
> For example, if an ALIAS can be IMPORTED, does it makes sense that it can
> be
> exported with export() and install(EXPORT)?
>
> If we have
>
>  add_library(CoreStatic ${Core_SRCS})
>  add_library(MyNS::Core ALIAS CoreStatic)
>
> and I export both of them with the NAMESPACE 'MyNS::', do I end up with
>
>  MyNS::MyNS::Core
>
> ?
>
> Or would the exporting code strip of everything before a '::' in the alias
> name?
>
> Or should exporting ALIAS targets still be disallowed?
>
> The two use cases described in
>
>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/52452
>
> seem like they would not benefit from exporting ALIAS targets.
>
> A reasonable way forward might be:
>
> * Keep the restriction that ALIAS targets may not be exported.
> * Remove the code disallowing ALIAS IMPORTED targets.
> * Remove the unit test proving it is not allowed
> * Add new unit tests that it basically works
> * Add a unit test for using an ALIAS with try_compile(LINK_LIBRARIES)
> * (Anything else that comes up along the way)
>
> Thanks,
>
> Steve.
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Allow ALIAS of IMPORTED targets

2015-09-14 Thread CHEVRIER, Marc 
Hi Michael,

If this feature can be supported for libraries and executables, it will be 
perfect for me.
Thank you.

Marc



On 12/09/15 23:48, "cmake-developers on behalf of Michael Scott" 
 
wrote:

>Hi,
>
>I'm planning on having a look at the CMake issue "Allow ALIAS of 
>IMPORTED targets", 0015569. After reading the thread between yourself 
>and Marc, I wanted to ask a couple of things before I start going 
>further with it.
>
>The proposed change would be for the add_library and add_executable 
>commands only right?
>
>Having a quick look at the code for those two commands, they 
>specifically check for a combination of ALIAS and IMPORTED and don't 
>allow it. I'm guessing that the required changes to allow both 
>simultaneously wouldn't be to just remove this check, there would be 
>other areas to modify as well right?
>
>Cheers,
>Michael
>-- 
>
>Powered by www.kitware.com
>
>Please keep messages on-topic and check the CMake FAQ at: 
>http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For more 
>information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>Visit other Kitware open-source projects at 
>http://www.kitware.com/opensource/opensource.html
>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Allow ALIAS of IMPORTED targets

2015-09-12 Thread Michael Scott 

Hi,

I'm planning on having a look at the CMake issue "Allow ALIAS of 
IMPORTED targets", 0015569. After reading the thread between yourself 
and Marc, I wanted to ask a couple of things before I start going 
further with it.


The proposed change would be for the add_library and add_executable 
commands only right?


Having a quick look at the code for those two commands, they 
specifically check for a combination of ALIAS and IMPORTED and don't 
allow it. I'm guessing that the required changes to allow both 
simultaneously wouldn't be to just remove this check, there would be 
other areas to modify as well right?


Cheers,
Michael
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers