Uploaded image for project: 'Qbs ("Cubes")'
  1. Qbs ("Cubes")
  2. QBS-1219

Practical Compiler Warnings

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Won't Do
    • Icon: Not Evaluated Not Evaluated
    • None
    • 1.8.1
    • General
    • None

      Summary: I think the current visual studio (but maybe others) compiler warning levels are too general to be of much use.

      Background:I'm very new to QBS and I'm currently trying to convert a small to medium sized multiplatform application to the QBS build system. It has 6 or 7 external libraries (tbb / armadillo / fftw) and qt.

      Problem 1: 'None' and 'All' don't provide enough granularity.

      Currently having the following is not very useful due to the amount of informational warnings generated:

         cpp.warningLevel: "all"
         cpp.treatWarningsAsErrors: true
      

      because although in an ideal world we'd have zero for all warning cases - we try and focus on the warnings which are going to have a practical effect.

      Possible solutions: I think adding a 'production' level in between the two levels, which enables the practical warnings. In Visual Studio this would be /W3. /W4 provides 'informational warnings' and 'WAll' turns on warnings which are off by default (see: https://msdn.microsoft.com/en-us/library/23k5d385.aspx)

      Current work-around:

      Properties {
         condition: qbs.targetOS.contains("windows")
         cpp.warningLevel: "none"
         cpp.cxxFlags: ["/W3"]
      }

       Unfortunately this adds this warning to the visual studio output:

      1>cl : Command line warning D9025: overriding '/w' with '/W3'
      
      Problem 2: Warnings are generated for QT, Moc Files and Visual Studio Includes.

      Building our very simple tools static library produces 14k warnings (see below for examples, they're all not very practical), roughly split between generated moc files, the included QT libraries and the MSVC includes. They slow down compilation due to their sheer number and the fact that they all get printed to console.

      These provide little use to me as I can't fix them directly. Even if I wanted to use -WAll for my project, they get drowned out by external libraries.

      Possible Solutions: These should be explictly opt-in. Anything external to the project.qbs (all external modules defined in qbsSearchPaths etc) should not show warnings unless explicitly enabled.

      Current Workarounds:

      For QT there's this profile hack that I found in the mailing lists:

      http://lists.qt-project.org/pipermail/qbs/2017-April/001709.html

      which replaces all the qt include paths with system include paths. This solves most (99%) of the QT and MOC warnings, but I still get warnings for qtcore inline functions and structs defined in the headers (not sure what's going on there). These warnings go away with /W3.

      I don't currently have a workaround for "all" for the VS headers in "c:\program files (x86)\microsoft visual studio\2017\enterprise\VC\Tools\MSVC\14.11.25503\include\" This warnings do go away if you use the /W3 above however.

      Examples of warnings:

      Moc files:

      Warning    C4464   relative include path contains '..'  
      Warning    C4820   '3' bytes padding added after data member 
      Warning    C4625   copy constructor was implicitly defined as deleted    
      Warning    C5026   move constructor was implicitly defined as deleted
      Warning    C4626   assignment operator was implicitly defined as deleted 
      Warning    C5027   move assignment operator was implicitly defined as deleted

      <memory>

      Warning    C4365    'argument': conversion from 'std::_Atomic_integral_t' to 'long', signed/unsigned mismatch

      <xlocale>

      warning C4365: '=': conversion from 'int' to 'unsigned long', signed/unsigned mismatch
      

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

            kandeler Christian Kandeler
            lmv Luke
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved:

                There are no open Gerrit changes