[CMake] Canonical way to amend location names
Stephan Menzel
stephan.menzel at gmail.com
Wed Nov 4 04:31:55 EST 2015
Hello,
I am currently bringing a rather complex CMake based build system up to
speed with current versions and hope to get rid of old quirks and
workarounds. One of which being the way I have to amend version information.
It is primarily used in a MSVC11 scenario and contains a number of macros
that wrap native CMake commands such as add_library.
My add_library contains code like that:
set(LIBSTRING "_${ARG_MAJOR}")
set_target_properties(${name} PROPERTIES SUFFIX "${LIBSTRING}.dll")
set_target_properties(${name} PROPERTIES IMPORT_SUFFIX "${LIBSTRING}.lib")
get_target_property(location ${name} LOCATION)
get_filename_component(location_we ${location} NAME_WE)
get_filename_component(path ${location} PATH)
set(pdbname "${path}/${location_we}.pdb")
set(pdbdname "${path}/${location_we}_d.pdb")
file(TO_NATIVE_PATH ${pdbname} result)
file(TO_NATIVE_PATH ${pdbdname} dresult)
set_target_properties(${name} PROPERTIES LINK_FLAGS_RELEASE
"/PDB:\"${result}\"")
set_target_properties(${name} PROPERTIES LINK_FLAGS_RELWITHDEBINFO
"/PDB:\"${result}\"")
set_target_properties(${name} PROPERTIES LINK_FLAGS_DEBUG
"/PDB:\"${dresult}\"")
This was used to maintain pdbs and add a "_d" suffix to dll names resulting
from debug builds. Main purpose however was to amend the resulting artifact
with LIBSTRING, which would transform a
add_library(mylib ... ) yielding mylib.dll
to
MY_ADD_LIBRARY(mylib ... MAJOR 1 MINOR 0) yielding a mylib_1.dll
There is quite an amount of code doing this and on recent CMake releases,
not set to old policies this yields errors such as:
The LOCATION property may not be read from target "mylib". Use the target
name directly with add_custom_command, or use the generator expression
$<TARGET_FILE>, as appropriate.
So I would gladly change all this to reflect the "canonical way" to solve
this, as long as it exists. So my questions are:
Does it? Is this functionality available in CMake nowadays without own code
or workarounds?
If yes, what is it?
If no, can I do this more elegantly without having to resort to old
policies?
Thanks for any advice,
Stephan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20151104/0b59f03c/attachment.html>
More information about the CMake
mailing list