[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