Patrick Stotko
2018-07-16 18:44:04 UTC
Hi,
since my first try of relaxing the limitation that target_link_libraries
may not be called in other directories was reverted due to a use case
that was not fully covered, a more promising approach has been developed
after a long but very insightful discussion which I wanted to present
here to collect some feedback from you.
In order to allow linking from another directory, the actual directory
where the RHS target was created (and should be found later via lookup)
needs to be encoded. The proposed solution would add a new syntax for
this (note the similarity to C++ lambda expressions):
[target_name]@{subdir}
This is necessary since it is not possible at all to use generator
expressions. The syntax would be specific to values in the
[INTERFACE_]LINK_LIBRARIES properties and not be meaningful elsewhere
(besides target_link_libraries arguments used to populate the
properties). Future extensions to this may include encoding of more
properties:
[target_name]@{prop1:value1;prop2:value2;...}
Special characters such as : and = will be disallowed now. Furthermore,
lists of targets may also be handled in some future extension:
[target1]@{"subdir"};[target2]@{"subdir"} => [target1;target2]@{"subdir"}
Note that these two extensions may or may not be included in some future
version. Our primary focus here lies on the basic use case of encoding
the directory property without limiting future generalizations. More
details and an in-depth discussion about the problem can be found in
this issue (https://gitlab.kitware.com/cmake/cmake/issues/17943). Please
share your thoughts regarding the proposed syntax and let us know
potential problems that should be tackled.
Best regards,
Patrick Stotko
--
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:
https://cmake.org/mailman/listinfo/cmake-developers
since my first try of relaxing the limitation that target_link_libraries
may not be called in other directories was reverted due to a use case
that was not fully covered, a more promising approach has been developed
after a long but very insightful discussion which I wanted to present
here to collect some feedback from you.
In order to allow linking from another directory, the actual directory
where the RHS target was created (and should be found later via lookup)
needs to be encoded. The proposed solution would add a new syntax for
this (note the similarity to C++ lambda expressions):
[target_name]@{subdir}
This is necessary since it is not possible at all to use generator
expressions. The syntax would be specific to values in the
[INTERFACE_]LINK_LIBRARIES properties and not be meaningful elsewhere
(besides target_link_libraries arguments used to populate the
properties). Future extensions to this may include encoding of more
properties:
[target_name]@{prop1:value1;prop2:value2;...}
Special characters such as : and = will be disallowed now. Furthermore,
lists of targets may also be handled in some future extension:
[target1]@{"subdir"};[target2]@{"subdir"} => [target1;target2]@{"subdir"}
Note that these two extensions may or may not be included in some future
version. Our primary focus here lies on the basic use case of encoding
the directory property without limiting future generalizations. More
details and an in-depth discussion about the problem can be found in
this issue (https://gitlab.kitware.com/cmake/cmake/issues/17943). Please
share your thoughts regarding the proposed syntax and let us know
potential problems that should be tackled.
Best regards,
Patrick Stotko
--
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:
https://cmake.org/mailman/listinfo/cmake-developers