# Get ride of \`Release\` on build path output
**URL:** https://discourse.cmake.org/t/get-ride-of-release-on-build-path-output/9381
**Category:** Usage
**Tags:** os:windows, comp:msvc
**Created:** [November 7, 2023, 10:43am UTC](https://discourse.cmake.org/t/get-ride-of-release-on-build-path-output/9381 "2023-11-07T10:43:20Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@skhaz](https://discourse.cmake.org/u/skhaz)
#### Post date: [November 7, 2023, 10:43am UTC](https://discourse.cmake.org/t/get-ride-of-release-on-build-path-output/9381/1 "2023-11-07T10:43:20Z")
How do I make CMake force MSVC to place the binary produced by the build in the “build” directory?
I ask because for all platforms (Linux, macOS & WebAssembly) the final binary is located in `build` , but only on Windows it’s in `build\Release\myproject.exe`.
So I would like to know how to remove the “Release” from the equation.
Thank you.
---
### Author:  [@scivision](https://discourse.cmake.org/u/scivision)
#### Post date: [November 7, 2023, 6:43pm UTC](https://discourse.cmake.org/t/get-ride-of-release-on-build-path-output/9381/2 "2023-11-07T18:43:02Z")
I’m not at my Windows computer but does this work?
```auto
set_property(TARGET myproject PROPERTY RUNTIME_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR})
```
From the docs it should work.
[https://cmake.org/cmake/help/latest/prop\_tgt/RUNTIME\_OUTPUT\_DIRECTORY.html](https://cmake.org/cmake/help/latest/prop_tgt/RUNTIME_OUTPUT_DIRECTORY.html)
---
### Author:  [@ksdhans](https://discourse.cmake.org/u/ksdhans)
#### Post date: [November 8, 2023, 2:10am UTC](https://discourse.cmake.org/t/get-ride-of-release-on-build-path-output/9381/3 "2023-11-08T02:10:57Z")
Just a quick warning about doing this: the reason it gets put into a “Release” subdirectory, is because MSVC has multiple build configurations. At bare minimum, you also have a Debug configuration. If you force the output binary into the main build directory, then the debug and release configurations will overwrite each other when you switch between configurations.
MSVC, Ninja Multi-Config, and XCode, are multi-config generators, and the rest are single configuration:
[https://cmake.org/cmake/help/latest/prop\_gbl/GENERATOR\_IS\_MULTI\_CONFIG.html](https://cmake.org/cmake/help/latest/prop_gbl/GENERATOR_IS_MULTI_CONFIG.html)
This is done because MSVC, & XCode have multiple configurations by default. This difference is annoying, and I wish that the CMake team would make all generators work the same way (i.e., make them all multi-config). For now, though, this is how it works.
---
### Author:  [@scivision](https://discourse.cmake.org/u/scivision)
#### Post date: [November 8, 2023, 3:08am UTC](https://discourse.cmake.org/t/get-ride-of-release-on-build-path-output/9381/4 "2023-11-08T03:08:00Z")
Right one might instead do
```cmake
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE ${CMAKE_CURRENT_BINARY_DIR})
```
and so on. Still have to have your comments in mind.
---
### Author:  [@One\_Cable5781](https://discourse.cmake.org/u/One_Cable5781)
#### Post date: [November 8, 2023, 11:02am UTC](https://discourse.cmake.org/t/get-ride-of-release-on-build-path-output/9381/5 "2023-11-08T11:02:26Z")
> I wish that the CMake team would make all generators work the same way (i.e., make them all multi-config).
I am trying to discern why you feel that the default should be multi-config? Currently, I use Ninja single config on both Linux [to generate makefile] as well as Windows (on Visual Studio IDE) [to generate .sln and .vcxproj files] and this allows me to query and correctly use CMAKE\_BUILD\_TYPE to conditionally set flow in my CML.txt based on whether it is a Debug build or a Release build. From my understanding, CMAKE\_BUILD\_TYPE is valid only in single config model.
I made a query in trying to understand this better over at /r/cmake
[https://www.reddit.com/r/cmake/comments/17qdvdj/usage\_of\_cmake\_build\_type\_vs\_generator\_expression/](https://www.reddit.com/r/cmake/comments/17qdvdj/usage_of_cmake_build_type_vs_generator_expression/)
If you have time, could you please elaborate here why Multi config is better (?) than Single Config? While I understand natively Visual Studio IDE is MultiConfig, I a currently able to still use Visual Studio IDE and cmake using Ninja single config generator. How would the workflow be better if everything were multiconfig?
---
### Author:  [@ksdhans](https://discourse.cmake.org/u/ksdhans)
#### Post date: [November 8, 2023, 12:20pm UTC](https://discourse.cmake.org/t/get-ride-of-release-on-build-path-output/9381/6 "2023-11-08T12:20:59Z")
> [@One\_Cable5781](#):
>
> I am trying to discern why you feel that the default should be multi-config?
Multi-config allows you to build both debug and release (and other configs) side by side without needing to reconfigure.
The closest you can get with single configuration generators, is to manually create separate debug and release build directories, and run the configuration step twice; once in each. This works, but is more tedious. It’s also slower, because every time reconfiguration needs to be done, it has to be done for every configuration (at least, the configurations that you are building regularly).
Making everything single-config would be better than what we have now. However, I do think that it’s easier to switch from single-config to multi rather than the other way round.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [November 17, 2023, 1:45pm UTC](https://discourse.cmake.org/t/get-ride-of-release-on-build-path-output/9381/7 "2023-11-17T13:45:39Z")
> [@ksdhans](#):
>
> MSVC, Ninja Multi-Config, and XCode, are multi-config generators
MSVC is the compiler; Visual Studio is the generator.
> [@ksdhans](#):
>
> Making everything single-config would be better than what we have now. However, I do think that it’s easier to switch from single-config to multi rather than the other way round.
The install trees get muddied as usually only Debug (typically) has different artifact names than other configurations.
---
### Author:  [@ksdhans](https://discourse.cmake.org/u/ksdhans)
#### Post date: [November 18, 2023, 9:02am UTC](https://discourse.cmake.org/t/get-ride-of-release-on-build-path-output/9381/8 "2023-11-18T09:02:54Z")
> [@ben.boeckel](#):
>
> The install trees get muddied as usually only Debug (typically) has different artifact names than other configurations.
Not sure what you mean by this.
The best argument for single-config, is that it’s easier to understand if/else statements rather than generator expressions. So much so, that I wish that the multi-config generators could process the if/else statements related to debug/release/etc.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [November 18, 2023, 8:12pm UTC](https://discourse.cmake.org/t/get-ride-of-release-on-build-path-output/9381/9 "2023-11-18T20:12:51Z")
> [@ksdhans](#):
>
> Not sure what you mean by this.
Debug libraries tend to be named `libfood.dll` while _all other_ configs tend to use `libfoo.dll`. One _can_ set a suffix for every config, but this is rarely done. On install, these will either overlap or embed the config into a directory name somewhere else.
> [@ksdhans](#):
>
> The best argument for single-config, is that it’s easier to understand if/else statements rather than generator expressions.
I agree that there’s a lot that is simpler.
> [@ksdhans](#):
>
> So much so, that I wish that the multi-config generators could process the if/else statements related to debug/release/etc.
Given that the content of the branches can be arbitrary, that sounds…difficult. I’m sure the case you’re thinking of are fine, but I don’t know how to restrict things to what is sensible.
---
### Author:  [@ksdhans](https://discourse.cmake.org/u/ksdhans)
#### Post date: [November 20, 2023, 7:25am UTC](https://discourse.cmake.org/t/get-ride-of-release-on-build-path-output/9381/10 "2023-11-20T07:25:55Z")
> [@ben.boeckel](#):
>
> Debug libraries tend to be named `libfood.dll` while _all other_ configs tend to use `libfoo.dll`. One _can_ set a suffix for every config, but this is rarely done. On install, these will either overlap or embed the config into a directory name somewhere else.
Ah, okay.
> [@ben.boeckel](#):
>
> > [@ksdhans](#):
> >
> > So much so, that I wish that the multi-config generators could process the if/else statements related to debug/release/etc.
>
> Given that the content of the branches can be arbitrary, that sounds…difficult. I’m sure the case you’re thinking of are fine, but I don’t know how to restrict things to what is sensible.
Yes, I think that would be difficult. The easiest way to get the results 100% correct would be brute force: execute the cmake scripts separately for each configuration, and update the multi-configuration generators to read variables on a per-config basis.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [November 20, 2023, 12:43pm UTC](https://discourse.cmake.org/t/get-ride-of-release-on-build-path-output/9381/11 "2023-11-20T12:43:59Z")
> [@ksdhans](#):
>
> execute the cmake scripts separately for each configuration, and update the multi-configuration generators to read variables on a per-config basis.
That still doesn’t work. What do we do if a project has:
```cmake
if (CMAKE_BUILD_TYPE STREQUAL "Release")
add_library(foo STATIC source1_fast.c)
else ()
add_library(foo SHARED source1_reliable.c)
endif ()
```
or other dark magic? How about:
```cmake
if (CMAKE_BUILD_TYPE STREQUAL "Release")
set(val 1)
else ()
set(val 2)
endif ()
configure_file(
config.h.in # uses `val`
config.h)
```
Projects that want to support Multi-Config need to consider this when writing their CMake code.
---
### Author:  [@ksdhans](https://discourse.cmake.org/u/ksdhans)
#### Post date: [November 20, 2023, 1:33pm UTC](https://discourse.cmake.org/t/get-ride-of-release-on-build-path-output/9381/12 "2023-11-20T13:33:17Z")
I don’t see an issue with add\_library(). If you’re literally executing the build script once per config, then all the output for each config should be passed to the generator. This includes per-config target/file lists, attributes, etc. Visual Studio projects routinely have static and shared configs, and I doubt that any of the other multi-config targets would have a problem with it.
You’re right that the configure\_file() code is potentially problematic. If config.h gets saved in the config’s build sub-directory, then everything would work just fine. If a script adds/modifies files directly in the source tree, then obviously you cannot have multiple build configs side-by-side at all. I sometimes have multiple build directories side by side with single-config generators. Each have their own config (e.g., debug, release, or even cross-compiling to different targets). I’d have some very confusing trouble if I tried that with a project that modifies the source tree directly.