Warnings: Feast or Famine
-
For those keeping score at home, I've solved all my issues except the one that brought me here, which is that I can't seem to get the actual compile to accept flags. I've tried putting 'QMAKE_CXXFLAGS += -Wall' everywhere I can, and it doesn't seem to affect the compile output.
If anyone has successfully made such a modification to their project on a Mac, please let me know where exactly you put the CXXFLAGS annotation (Specific menu, screen, file, whatever.)
-
@kenchan said in Warnings: Feast or Famine:
There are also these two
QMAKE_CXXFLAGS_WARN_ON
QMAKE_CXXFLAGS_WARN_OFFThe question isn't which flags, it's where to put them. Have you successfully applied these flags to a (Mac) project? If so, how?
-
More experimentation, more data:
The project I'm working on has numerous .pro files, as it consists of a main app which depends on several in-house and third-party libraries. So I have a choice of where to try putting QMAKE_CXXFLAGS lines.
Firstly, though, here is a typical build call from the current Compile Output:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -c -pipe -stdlib=libc++ -g -std=gnu++11 -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -mmacosx-version-min=10.12 -Wall -W -fPIC -Dappstore -DQT_QML_DEBUG -DQT_NETWORK_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I../../qtmasterfader/MasterFaderCore -I. -I/Users/abroad/Documents/qtmasterfader/SubmoduleIncludes/../QtZeroConf_debug -I../../qtmasterfader/MasterFaderCore/easyexif -I../../../Qt5.12/5.12.1/clang_64/lib/QtNetwork.framework/Headers -I../../../Qt5.12/5.12.1/clang_64/lib/QtGui.framework/Headers -I../../../Qt5.12/5.12.1/clang_64/lib/QtCore.framework/Headers -I. -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/Applications/Xcode10.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/OpenGL.framework/Headers -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/Applications/Xcode10.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/AGL.framework/Headers/ -I../../../Qt5.12/5.12.1/clang_64/mkspecs/macx-clang -F/Users/abroad/Qt5.12/5.12.1/clang_64/lib -o device.o ../../qtmasterfader/MasterFaderCore/device.cpp
Note that -Wall and -W (which is the same as -Wextra) are already set! However, they do not appear to be working, as constructions flagged by -Wall in the analyzer aren't showing up in the Compile Output. This is now the heart of the mystery.
If I add, e.g. -Wold-style-cast to:
- the main project .pro file, nothing happens. The flag doesn't show up in the compile output at all.
- the app project .pro file (where 'main.cpp' resides), the flag shows up in the compile output for all the source files in that part of the project, and they generate old style cast related warnings.
- particular libraries' .pro files, the flag shows up in the compile output for the source files for that particular library, and they generate warnings.
So there doesn't appear to be a way to apply flags to the entire build at once, but I was wrong, in that I do appear to be able to set flags via QMAKE_CXXFLAGS in .pro files. It's just that -Wall is apparently 1) already set via some other mechanism, and 2) not working.
Does anyone know why -Wall -W doesn't seem to generate any warnings in the compiler, but does in the editor or analyzer?
-
@wumpus7
Yes i use it on a mac in my single pro file.If you look in the file called gcc-base.conf in the <path to your Qt install>clang_64/mkspecs/common folder you can see how all the flags are used.
Take a look at the qmake.conf file under the mkspecs/macx-clang folder to see what is used when building on a mac. -
@kenchan - Thanks for replying. I kind of feel like I'm in freefall now, having looked in more detail into those .conf files. I can't begin to parse them or how they work. (E.g. I see both the QMAKE_CXXFLAGS_WARN_ON and _OFF are defined in the base .conf, but have no idea how/where they are invoked.)
Further, I discovered the reason that there were no warnings coming from one of the major libraries: someone had put 'CONFIG+=warn_off' into its .pro file. Do you know where warn_off is 'declared/defined'? It seems to the 'user' switch for the _WARN_ON/_OFF flags you recommended.
Of course, while removing warn_off creates tons of warnings, putting 'QMAKE_CXXFLAGS += -Wno-missing-braces' (thousands of these is a autogenerated header file) in its place seems to have no effect. I really don't understand what I'm doing, or how I'm supposed to know what I'm doing - this seems like an entire parallel set of complex build instructions that can only be navigated file by file.
I've never had so much trouble with an IDE before; are these things I'm trying to do (turn on/off specific warnings) supposed to be so difficult?
-
@wumpus7
I am sure you have looked at the Qmake documentaton but if you here you can see where the "warn_off"
flag is predefined for CONFIG.
Beyond that I cannot claim to be a qmake guru so am afraid I am also getting out of my depth.
BTW, I could not find a -Wno-missing-braces item in the clang documentation maybe that is the problem. -
@kenchan - Again, thanks. I've successfully used -Wno-missing-braces on the analyzer and editor, so it 'works' for at least some versions of the compiler.
As for 'warn_on'/'warn_off', I had no trouble verifying their existence/function once I found them in the .pro file, but I had no prior warning to look for such a thing. I've been looking for QMAKE_CXXFLAGS, not weird macros that are defined in some middle ground between the .conf files and the .pro files. I don't understand how the .conf files work, much less how to successfully invoke half of the options documented there and elsewhere.
On the other hand, I think that I've solved my main issue with the discovery of the hidden 'warn_off' in my library's .pro file. I have compile warnings again. More than I'd like, true, and I don't seem to be able to turn off specific warnings, but fixing the autogenerated code should get rid of the majority of the offending bits, so I can at least have some confidence in my builds again.