[JENKINS-58351] buildType is used incorrectly for visual studio builds

[jenkins-infra-bot]

I have created a Jenkins pipeline that covers both windows and linux.

However it appears that cmakeBuild does not use buildType correctly for visual studio

For Linux is correctly adds -DCMAKE_BUILD_TYPE=Debug or Release in the configure step

However for windows the CMAKE_BUILD_TYPE variable is ignored:

17:47:24    Manually-specified variables were not used by the project:
17:47:24  
17:47:24      CMAKE_BUILD_TYPE

And subsequently in the --build step, the --config is unused. Resulting in a Debug-by-default build with the visual studio generator.

-config Debug or -config Release (depending on buildType should be added to the --build phase for windows (and CMAKE_BUILD_TYPE should not be used for visual studio generator)

 

The current workaround to this is adding --config Debug/Release explicitly in the steps:

steps: [[args: '--config Debug', withCmake: true]]

Which of course is less than ideal if the buildType property is available.

---

Originally reported by dennis_cappendijk, imported from: buildType is used incorrectly for visual studio builds

• assignee: 15knots
• status: Open
• priority: Minor
• component(s): cmakebuilder-plugin
• resolution: Unresolved
• votes: 0
• watchers: 2
• imported: 20260124-160229

Raw content of original issue

I have created a Jenkins pipeline that covers both windows and linux.

However it appears that cmakeBuild does not use buildType correctly for visual studio

For Linux is correctly adds -DCMAKE_BUILD_TYPE=Debug or Release in the configure step

However for windows the CMAKE_BUILD_TYPE variable is ignored:

17:47:24    Manually-specified variables were not used by the project:
17:47:24  
17:47:24      CMAKE_BUILD_TYPE


And subsequently in the --build step, the --config is unused. Resulting in a Debug-by-default build with the visual studio generator.
-config Debug or -config Release (depending on buildType should be added to the --build phase for windows (and CMAKE_BUILD_TYPE should not be used for visual studio generator)
 
The current workaround to this is adding --config Debug/Release explicitly in the steps:

steps: [[args: '--config Debug', withCmake: true]]


Which of course is less than ideal if the buildType property is available.

environment

Windows + visual studio 2015 / Linux + unix makefiles<br/>
Jenkins ver. 2.176.1<br/>
cmake builder plugin Version 2.6.2

[jenkins-infra-bot]

15knots:

• Original comment link
• Raw content of original comment:

  Cmake's evaluation of the CMAKE_BUILD_TYPE variable is not specific to the OS, it is specific to the buildscript generator.
  
  For the VS generator, apparently even the cmake guys could not find a way to generate build scripts for the VS build tool that pass the CMAKE_BUILD_TYPE-corresponding compiler/linker options to the compiler/linker. So users must take care to pass the
  
  '--config Debug'
  
  to the VS build tool themselve.
  As a workaround, you might want to try the nmake or nmake-jom generators.
  

Cmake's evaluation of the CMAKE_BUILD_TYPE variable is not specific to the OS, it is specific to the buildscript generator.

For the VS generator, apparently even the cmake guys could not find a way to generate build scripts for the VS build tool that pass the CMAKE_BUILD_TYPE-corresponding compiler/linker options to the compiler/linker. So users must take care to pass the

'--config Debug'

to the VS build tool themselve.

As a workaround, you might want to try the nmake or nmake-jom generators.

[jenkins-infra-bot]

dennis_cappendijk:

• Original comment link
• Raw content of original comment:

  Would it be possible to add this as an improvement to the plugin? Ie, when a visual studio generator is set to the generator property use config instead of CMAKE_BUILD_TYPE or would this be too custom?
  
   
  

Would it be possible to add this as an improvement to the plugin? Ie, when a visual studio generator is set to the generator property use config instead of CMAKE_BUILD_TYPE or would this be too custom?

 

[jenkins-infra-bot]

dennis_cappendijk:

• Original comment link
• Raw content of original comment:

  Adapted ticket title and description to better reflect the issue, thanks 15knots 
  

Adapted ticket title and description to better reflect the issue, thanks 15knots

[jenkins-infra-bot]

15knots:

• Original comment link
• Raw content of original comment:

  Would it be possible to add this as an improvement to the plugin? Ie, when a visual studio generator is set to the generator property use config instead of CMAKE_BUILD_TYPE or would this be too custom?
  I do not think an implementation will be easy, and if so, be of much use.
  
  Remember, users may enter an arbritrary value for the build type (this is because users may define custom build-types in their CMakeLists.txt). Therefore, it is not possible to define a mapping of <custom build type> (in effect with the Makefiles generator on linux) to --config <whatever VS build needs> (in effect with the VS  generator on windows) in the plugin. Of course, the plugin could offer a way to define that mapping in its UI to solve the problem. But such an UI would be confusing to users and the pipeline UI is text based; making the cmakeBuild invocation code nearly unreadable if someone uses the snippet generator.
  
  Apart the mapping problem,  my other concerns on implementing the improvement are
  
  	
  It  would require to build up a knowledge base that tracks
  	
  
  		
  which generator needs the CMAKE_BUILD_TYPE variable at script generation time,
  		
  which generator needs an extra option to specify the build-type at build time and what the name of the option is.
  	
  	
  	
  Maintenance effort of that knowledge base (Permanent maintenance is required in case cmake comes with new generators).
  
  
  
  Another obstacle: Users may specify an empty value for the generator, leaving the generator choice to cmake, depending on the OS your code is build on. Could be solved by an extra knowledge base that tracks cmake's default generator choice. Until a problem with a future revision of cmake that  switches to a different default generator, which again could be solved  by a permanently maintained knowledge base.
  
  Citations:
  
  Chuck Berry: Too much monkey business.
  
  Kevlin Henney: Except for the problem of too many layers of indirection
  

Would it be possible to add this as an improvement to the plugin? Ie, when a visual studio generator is set to the generator property use config instead of CMAKE_BUILD_TYPE or would this be too custom?

I do not think an implementation will be easy, and if so, be of much use.

Remember, users may enter an arbritrary value for the build type (this is because users may define custom build-types in their CMakeLists.txt). Therefore, it is not possible to define a mapping of (in effect with the Makefiles generator on linux) to --config (in effect with the VS  generator on windows) in the plugin. Of course, the plugin could offer a way to define that mapping in its UI to solve the problem. But such an UI would be confusing to users and the pipeline UI is text based; making the cmakeBuild invocation code nearly unreadable if someone uses the snippet generator.

Apart the mapping problem,  my other concerns on implementing the improvement are

1. It  would require to build up a knowledge base that tracks
   1. which generator needs the CMAKE_BUILD_TYPE variable at script generation time,
   2. which generator needs an extra option to specify the build-type at build time and what the name of the option is.
2. Maintenance effort of that knowledge base (Permanent maintenance is required in case cmake comes with new generators).

Another obstacle: Users may specify an empty value for the generator, leaving the generator choice to cmake, depending on the OS your code is build on. Could be solved by an extra knowledge base that tracks cmake's default generator choice. Until a problem with a future revision of cmake that  switches to a different default generator, which again could be solved  by a permanently maintained knowledge base.

Citations:

Chuck Berry: Too much monkey business.

Kevlin Henney: Except for the problem of too many layers of indirection