[cmake-developers] target-LOCATION-policy topic
Steve,
Please extend the CMP0026 message to suggest file(GENERATE)
as a way of putting the target location in a generated file.
Some projects not supporting multi-config generators may
use LOCATION with configure_file.
Also, this policy means it will not be possible for a project
to support both the next release of CMake and CMake 2.8.4
unless it sets the policy to OLD, and 2.8.4 is not too old.
Generally I prefer to recommend against ever setting a policy
to OLD instead of fixing the code except in an existing project
release maintenance branch to quiet the warning.
Can the policy NEW behavior instead be to return the LOCATION
as a $TARGET_FILE:... generator expression? That would
allow projects to do
if(POLICY CMP0026)
cmake_policy(SET CMP0026 NEW)
endif()
get_property(loc TARGET myexe PROPERTY LOCATION)
add_custom_command(... ${loc} ...)
and work with both CMake 2.8.4 and with whatever release
includes the policy.
Thanks,
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target-LOCATION-policy topic
Brad King wrote:
Steve,
Please extend the CMP0026 message to suggest file(GENERATE)
as a way of putting the target location in a generated file.
Some projects not supporting multi-config generators may
use LOCATION with configure_file.
Done.
Can the policy NEW behavior instead be to return the LOCATION
as a $TARGET_FILE:... generator expression? That would
allow projects to do
if(POLICY CMP0026)
cmake_policy(SET CMP0026 NEW)
endif()
get_property(loc TARGET myexe PROPERTY LOCATION)
add_custom_command(... ${loc} ...)
and work with both CMake 2.8.4 and with whatever release
includes the policy.
I don't know. That seems like a lot of magic and bound to break existing
code.
get_property(loc TARGET myexe PROPERTY LOCATION)
file(WRITE some_script.bat ./${loc})
KDE4 does this:
get_target_property(_executable ${_target_NAME} LOCATION )
set_target_properties(${_target_NAME} PROPERTIES WRAPPER_SCRIPT
${_executable})
and the WRAPPER_SCRIPT is used elsewhere.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target-LOCATION-policy topic
On 10/11/2013 03:21 PM, Stephen Kelly wrote:
Brad King wrote:
Can the policy NEW behavior instead be to return the LOCATION
as a $TARGET_FILE:... generator expression?
I don't know. That seems like a lot of magic and bound to break existing
code.
get_property(loc TARGET myexe PROPERTY LOCATION)
file(WRITE some_script.bat ./${loc})
Yes, but that code will get the policy warning until someone
reads the policy documentation, sets it to NEW, and then
takes responsibility for using the new behavior properly.
OTOH, there is too much danger of setting it in one place
and having that silence the warning in other places instead
of generating an error on them.
Instead projects can do
if(NOT CMAKE_VERSION VERSION_LESS 2.8.4)
# use $TARGET_FILE:...
else()
# use LOCATION property
endif()
to support all versions regardless of the policy setting.
It is more verbose but more explicit, and projects can
potentially switch to this approach right now even before
the policy is introduced.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
