Search code examples
visual-studio-codecmakelinker

Which is the effect of switching between Debug and Release for a CMake project in Visual Studio Code?

What I want to accomplish is to link libraries of the same name but from different paths.

Currently I'm helping myself with

link_directories(${FOREIGN_DIR}/arch/win32/apil/access/x64/${CMAKE_BUILD_TYPE})

and later link the foreign_lib.lib so:

target_link_libraries(${LIB_NAME} ${CMAKE_JS_LIB} foreign_lib ${EXTRA_LIB})

EDIT: I am building with Ninja (single configuration type)

foreign_lib.lib obviously exists in a debug and release variant in a properly named subdirectory as you can see above, but both have the same name and I can't influence this.

Also I have to set the CMAKE_BUILD_TYPE myself further up the script as it is empty (the docs for that variable are as usual worthless) which is just a placeholder and also ugly/bad practice as I understand.

What I don't understand:

The CMake-tools in VisualStudio Code offer me the well-known options Debug, Release, MinSizeRel, RelWithDebInfo but I fail to understand how this can be correctly employed in the config step.

How does one go about linking in such a scenario correctly?

PS: integrating further variation by factoring in architecture (x64, Win32...) and target system (linux,x64, ...) would be a plus but my main concern is the above problem RN.

Solution

  • How does one go about linking in such a scenario correctly?

    See https://stackoverflow.com/a/74077157/11107541 for starters. The commandline methods for configuring/building with different build configurations differ for single-config and multi-config generators. CMake Tools will/should do the right thing based on the type of your selected generator, whether you are using Kits or Presets (but if you are using presets, you have to do the right thing in cache variables for single-config, and in configuration property of build preset for multi-config generator).

    Also I have to set the CMAKE_BUILD_TYPE myself further up the script as it is empty (the docs for that variable are as usual worthless) which is just a placeholder and also ugly/bad practice as I understand.

    You're supposed to use a generator expression.

    In general, don't use ${CMAKE_BUILD_TYPE}. As you've noticed, it doesn't need to be set for single-config generators (in which a toolchain-specific default is used). The docs are pretty clear:

    This variable is initialized by the first project() or enable_language() command called in a project when a new build tree is first created. If the CMAKE_BUILD_TYPE environment variable is set, its value is used. Otherwise, a toolchain-specific default is chosen when a language is enabled. The default value is often an empty string, but this is usually not desirable and one of the other standard build types is usually more appropriate.

    The generator expression you want is $<CONFIG>, or to use $<CONFIG:cfgs> to map to other values.

    PS: integrating further variation by factoring in architecture (x64, Win32...) and target system (linux,x64, ...) would be a plus but my main concern is the above problem RN.

    There are the PLATFORM_ID generator expressions, and you can use the CMAKE_GENERATOR_PLATFORM and CMAKE_GENERATOR_TOOLSET variables in an if() block to condition your link_directories call.