Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-58351

buildType is used incorrectly for visual studio builds

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • cmakebuilder-plugin
    • None
    • Windows + visual studio 2015 / Linux + unix makefiles
      Jenkins ver. 2.176.1
      cmake builder plugin Version 2.6.2

      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.

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

          Martin Weber added a 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.

          Martin Weber added a 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.

          Dennis Cappendijk added a comment - - edited

          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?

           

          Dennis Cappendijk added a comment - - edited 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?  

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

          Dennis Cappendijk added a comment - Adapted ticket title and description to better reflect the issue, thanks 15knots

          Martin Weber added a 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

          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

          Martin Weber added a 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

            15knots Martin Weber
            dennis_cappendijk Dennis Cappendijk
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: