I am building a C++ project using clang-tidy as linter (cmake -DCMAKE_CXX_CLANG_TIDY=clang-tidy).
After updating my system (Fedora 28->29, cmake 3.11->3.12 I believe), I cannot build any more when clang-tidy reports some clang-diagnostic-error (which I cannot fix right now...). I am pretty sure that clang-diagnostic-error's did not interrupt the build earlier... But I cannot be hundred percent sure.
Edit: The change happened in clang-tidy, now it returns a non-zero exit code when errors are found.
Is it possible to suppress those errors, something like the opposite of "-warnings-as-errors"?
Not sure if a solution or a workaround, but this does the trick (in my OS...):
cmake -DCMAKE_CXX_CLANG_TIDY="${PATH_TO_SCRIPT}/suppress_exit_status.sh;clang-tidy"
PATH_TO_SCRIPT to script is the absolute path to suppress_exit_status.sh, which looks like:
#!/bin/sh
$#||echo Command \"$#\" failed with exit code $?
|| is the "or" operator, the second operands is only executed if the first one fails. It seems that cmake captures standard error from the command and throws it way, hence the error message.
I could not figure out a more elegant way to do this, it is not possible to throw || directly into CMAKE_CXX_CLANG_TIDY.
Related
I want to use VS code as my C++ IDE. I installed it from the AUR(I'm using linux). But I got a bug. I tried to solve it following this topic. My json task is like the one in the topic i just linked to. But I got an error that read :
make: *** No rule to make target 'makefile'. Stop.
The error looks like it is coming from your makefile. (Assume you already installed C/C++ support)
Check your makefile in the command line to make sure there is no mistake.
taskName is passed as the first argument of the command. So if your command is "make" and your taskName is "makefile", the command line will be make makefile, leading to the error you are getting.
To avoid this behavior, add "suppressTaskName": true, inside the task declaration.
I'm not sure whether or not this question has a causality with my previous question.
So, I compiled Qt 5.3.1 from source with MinGW 4.8.2. The build stopped at qtbase/src/printsupport directory, as you can see the image below:
Is it a bug or something at qtbase/src/printsupport/kernel/qprintengine_win.cpp file? Then, should I just report it to the developer?
Look here it give you a hint. Probably somewhere you use this key -Werror in make files implicitly or explicitly when start compilation with gcc. If I correct understand error in that switch operation must be default: statement or case PPK_CustomBase: statement.
miraiE,
If you will notice in your output: cc1plus.exe: all warnings being treated as errors
This is, as was mentioned before, a warning that is stopping the compile process as an error.
You should be able to run you configure.bat script again, with the option -no-warnings-are-errors.
Then re-run your make.exe to get past this, and other warnings, from stopping the build.
Details of the specific configure options below:
../qtbase-opensource-src-5.3.1/configure --help |grep -i warn
-silent ............ Reduce the build output so that warnings and errors
-no-warnings-are-errors Make warnings be treated normally
-warnings-are-errors Make warnings be treated as errors
I hope this helps!
When I'm compiling ism project to create MSI, its still creates the MSI even though I have build errors.
The reason I need it NOT to be created is for build verification.
Instead of checking the build log for errors, I will just check the existence of the MSI.
Does anybody know how can I achieve that?
EDIT:
I'm using ISCmdBld tool to build MSIs. This is the command line I'm running to build where the environment variables are being set before running this command:
IsCmdBld -p "%FULL_PROJECT_FILENAME%" -a %BUILDMODE% -r %PRODUCT% -o "%MMSEARCHPATH%" | tee /A "%FULL_PROJECT_LOG_FILENAME%"
If you are compiling using IsCmdBld.exe, you should add the -x option, so that the build is stopped if an error occurs.
You also can use it combined with -w, which makes each warning becomes considered as an error (and thus, each warning encountered also stops the build).
More information about IsCmdBld.exe : http://helpnet.installshield.com/installshield16helplib/ISCmdBldParam.htm
I hope this helps.
Your build automation should check the exit code from ISCmdBld.exe. If the exit code is a failure, don't archive the output.
I recently discovered the Failures into Break-Points - option from googletest using the command line option gtest_break_on_failure or by defining the GTEST_BREAK_ON_FAILURE environment variable.
I gave it a try using gtest_break_on_failure. From command line, I saw no effect (to be honest I had the glimpse of hope that VS2010 would be registered as debugger and somehow magically would pop up and point to the error source).
Using it in the VS environment as command line argument a failed assertion triggered a break but the call stack did not include the test method that caused the failure. I found the work around to step (F10) until I reached my test code, but that does not really seem to be convenient.
Is it somehow possible to use the option from command line ?
Has anybody a recommendation how to get the correct call stack in the environment?
From VS, you can add --gtest_break_on_failure to the Command Args in the target's Property Pages, then just run the exe without stepping over.
From the command line, you should be able to run the Debug executable with the flags --gtest_break_on_failure --gtest_catch_exceptions=0 and this should allow you to break into the MSVC debugger when the test fails.
Command /Developer/usr/bin/g++-4.2 failed with exit code 1
build error
My project was working fine with no errors, and I went to run it again without changing anything and received this error (only this). Any ideas on how to fix it?
I had this error when certain .cpp files didn't exist, but it could be caused by any number of things. Clearly in your case it's something different, if you're sure you haven't changed anything in the project.
On the right of the build results list there should be a (well hidden) button with lines - that shows the raw build output, which should give you some idea about what went wrong. What does that say?