Feature Request: Name Mangling Machinery for External Projects
A per https://gitlab.kitware.com/ben.boeckel
Regarding the bit of a rat's nest issue: #17212 (comment 308671)
And heeding advice on breaking above out into at least three separate issues of which this is one. This here is a consolidation of the VS Runtime lack of name mangling issues
- Provide mechanism for library and exe name mangling for VS versions and runtimes including in Superbuilds and Superbuilds of Superbuilds. This is to say a mechanism to reach into superbuilds or mod default CMake to support standard (boost like) name mangling. An CMAKE_VAR allowing config of any cmake var that would span superbuilds of superbuilds might prove usefull.
ITK does at version it's libs, but that is not all that is required on Windows such as the need for vs runtime version name mangling and for superbuilds to realize the need for a build (note I did not say rebuild as what the prior vs ver build should not be overwritten if new VS ver is then selected). Also cmake-packages could use with vs-ver runtime mangling.
Visual Studio Runtimes and superbuilds:
The problem of visual studio runtimes vc120 and mt vs mtd which boost lib naming convention handles with names like:
boost_system-vc120-mt-1_60.lib
if you have seen errors like:
error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MDd_DynamicDebug' doesn't match value 'MD_DynamicRelease' in some.obj
or say
LNK2038: mismatch detected for '_MSC_VER': value '1600' does not match value '1700' when linking to itk or vtk after switching VS versions in build tree.
CMake superbuild will tell you it's installed and built but is it? Well all the lib names are there of the correct version, but that version is not all that is needed and VS will certainly contradict CMake. I think actually CMake contradicts is self here as when rebuilding the cache the SuperBuild/ExternalProject_Add should sense this and does not.
If you have been there you know right about now what I am talking about, can CMake handle the problem from a build and packaging name mangling perspective. I have been there when using multiple VS versions on same build tree rebuilds when switching tools this can get a little irritating when CMake Superubild does not recognize the need to rebuild, but even if it did it would be writing over build files. Name decorating keeps host from running incorrect lib or compiling over another or using the wrong lib to link that was previously built. Some arguments could be made for using CMAKE_<CONFIG>_POSTFIX
, but what about reaching into a superbuild of superbuild (VMTK)? There I have to checkout tree and patch it myself and store in my own git repo.