Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-49487

Scrap the #qmake_warning mechanism

    XMLWordPrintable

Details

    • Suggestion
    • Resolution: Done
    • P3: Somewhat important
    • 5.6.0 RC
    • 5.6.0 Alpha
    • Build tools: qmake
    • None
    • 93466161cacfb45b9de94d5cb8f0ee7be28db53a

    Description

      Since time immemorial, qmake has supported a "preprocessor directive"

      #  qmake_warning  arbitrary 'message\' "text\"
      

      (If the first non-space character of the message text is a quote, single or double, the text from it to the next such is used as message text; otherwise, the rest of the line is used. No attempt is made at escape-handling or at dealing with strings starting other than right after the keyword and space.)

      This message is probably meant to be output where the user can see it.
      However, in fact, it is never emitted unless qmake has been passed at least one -d option.
      The author (or a casual reader) might be forgiven for expecting debug_msg(0, ...) to trigger even when no -d options were passed, but the actual macro-expansion doesn't treat debug_msg as a function, it just replaces it with

      if(Option::debug_level) debug_msg_internal
      

      Now, debug_msg_internal(0, ...) would indeed output our message even if Option::debug_level is 0 (i.e. no -d was passed) but the macro's pre-test means we never get into this actual function.
      We would need macro-varargs to make this work properly.

      Consequently this "feature" has never worked except when -d is passed, which would cause its output to be lost in the vast amount of noise that comes even at debug level 1.

      In actual C++ source code, furthermore, any use of #qmake_warning would need to be suppressed, e.g. inside #if 0...#endif, since #qmake_warning isn't a legitimate preprocessor directive, so the actual compiler would choke on it. (The parser in qmake is oblivious to #if-ery, so #if 0...#endif won't hide it from qmake, only from the real compiler.) However, in UI files, it's possible a #qmake_warning make some kind of sense; I know nothing of the UI file format. I see no evidence of any use of #qmake_warning in any part of a full qt5 source tree, complete with its sub-modules.

      I propose that we simply rip out this untested impractical feature.
      Otherwise, I'll find myself wasting effort trying to fix it ...

      Attachments

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

        Activity

          People

            Eddy Edward Welbourne
            Eddy Edward Welbourne
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes