PVS-Studio now supports any build system on Windows and any compiler. Easy and out of the box

Now in PVS-Studio we are making a bomb!



In the next version, PVS-Studio 5.15 will be able to check projects that are assembled absolutely in any build system: Makefile, Visual Studio Project, own build system based on Python, Bash, or whatever ... Now we can simply “observe” the compiler calls. And collect all the necessary information to run the analysis automatically. Moreover, it works with any (reasonable) C / C ++ compiler that runs on Windows. Want details?

')

How does the plug-in for Visual Studio work and why did it limit its use?

Initially, PVS-Studio is a plugin for Microsoft Visual C ++. Interaction with the development environment consists of two aspects. First, it is integration into the user interface. It is convenient to work with the tool from the usual environment. Secondly, it is getting the file compilation parameters in order to carry out the correct analysis.



For those who are not very familiar with the mechanism of operation of code analyzers (and in particular, PVS-Studio), I will remind you. Before the analysis, it is necessary to perform the preprocessing, i.e. reveal all #include and #define. This is done in order to learn additional information about the types of data used above all.



The PVS-Studio plugin collected compilation parameters using the Visual Studio API and started preprocessing on its own. Now we have learned to keep track of what parameters the compiler is launched with and “repeat” its call with the key “perform preprocessing”. And then run the analyzer. This does not change anything for the plugin, and the old mechanism remains in it. But for some projects (even for some native Visual C ++ projects) this mechanism could not be used. What cases are we talking about?



First, if you have a Makefile project that is built, for example, using nmake. At that time, the Visual Studio API did not allow the plugin to know the compilation parameters and to cause preprocessing. Of course, you could always embed the PVS-Studio call into the Makefile. But let's be honest, this is not the most convenient solution that can be offered. No, of course, we have users who use PVS-Studio in this way. But many such a script scared.



Secondly, if you have a self-made build system that calls the compiler from scripts, then at least it looks like a Makefile, but only in theory. In practice, such an assembly system can often be modified only by its author, who may not be available. And it’s almost impossible to try PVS-Studio on such a project.



In other words, situations often arose, which seems to be a project being built by the Visual C ++ compiler, and there is a desire to try PVS-Studio. But it turned out to be not very easy and the desire smoothly disappeared ...

How do we solve this problem?

We have developed a special compiler call monitoring utility. It works with the main compilers for Windows, but, as before, our main focus is: Visual C ++ users.







The monitoring tool simply intercepts all calls to the compiler and then starts the compiler again with the parameters "preprocess the file", after which it calls the analyzer. The main charm is that all this is done absolutely transparent to the user and anyone can repeat it.



And we provide two different ways to take advantage of this opportunity.

Option 1 - Monitoring with a graphical interface

So, suppose you got access to the Unreal Engine 4 sources. You open a solution in Visual Studio and see that this is an nmake-based project, so you cannot check it with the PVS-Studio plugin. It's not a problem. You do the following:

1. Run PVS-Studio Standalone.
2. Click the "Compiler Monitoring" button, where you select the x64 platform for monitoring. Indeed, in Unreal Engine 4 you will build a 64-bit version.
3. By clicking on the “Start Monitoring” button you will see that the monitoring mode for the compiler calls has been turned on.
4. Now you go to Visual Studio and click the Build button - the project build went. At the same time, in the monitoring window, you can see that the compiler calls are intercepted. Note that the number of intercepted calls is written there, not the number of files with the code. The fact is that often the compiler is run with several files in arguments. Therefore, the number of compiler runs is less than or equal to the number of files.
5. When the build in Visual Studio is over, you click the Stop Monitoring button. And then the work of PVS-Studio begins. Files are preprocessed and analyzed. Diagnostic messages appear in the PVS-Studio Standalone utility window. You can immediately start working with them. But I recommend waiting for the analysis to be completed, save the result of the check to the UE4.plog file. Then close the PVS-Studio Standalone, open the UE4.plog file from the Visual Studio environment using the PVS-Studio menu and work with the test results there. Why? Yes, because in Visual Studio you will have IntelliSense, and you can easily navigate through the code, watch the values ​​of macros, look for variable declarations. Of course, all this can be done in PVS-Studio Standalone, but let's be honest - our tool is far from ease of use to Visual Studio.

In such a simple way, you can check projects using the monitoring GUI in PVS-Studio. But it is also convenient to start monitoring from the command line? About this in the next section.

Option 2 - Monitoring with the command line interface

But it also happens that the graphical user interface for monitoring is not very convenient. Suppose we want to test Qt 5.2 . To do this, we download the distribution in the form of an archive, unpack it. We start Visual Studio 2012 Command Promt (for the right environment), go to the folder with Qt and do the following:

1. We start the monitoring mode:

"C: \ Program Files (x86) \ PVS-Studio \ CLMonitor.exe" monitor



The program will end immediately, but will leave a “tracking module” in memory.

1. Run configure.exe - this is a program from the Qt package that prepares a script for the build.
2. Run nmake - sit back and wait until Qt is assembled.
3. When the Qt build is complete, you need to tell the monitoring that it's time to stop monitoring and start doing the analysis (for the Win32 platform, save the results to a log):

"C: \ Program Files (x86) \ PVS-Studio \ CLMonitor.exe" analyze C: \ Qt5.log Win32

1. When the analysis is completed, the result of the analyzer will be saved in a log file. I do not recommend working with the log directly. It is better to open it in PVS-Studio Standalone, it is much more convenient to work with the log there.

As you can see, checking projects with any build system from the command line is just as easy as using the user interface. Same 5 simple points.

About problems and limitations

We have not (yet?) Identified any fundamental problems in the monitoring technology. But some of the nuances should still know.



First, monitoring intercepts all calls to the compiler. And this means that if you run several different processes on the assembly, then everyone will be intercepted. And analyzed. That is, the test results will be porridge from the correct and "foreign" project. Do not forget about it and do not start any other assembly processes during the monitoring operation.



Secondly, sometimes there are nuances with precompiled headers. It often happens that the path to the precompiled headers is not in the list of include folders. At the same time, the compiler finds such headers, but the preprocessor (which is part of the compiler!) Does not find it anymore. Here the solution is simple - explicitly add the path to some include files with the list of include folders.

Trial mode

Now a small fly in the ointment. PVS-Studio has a trial mode, which limits clicks in the list of detected problems. However, when using PVS-Studio from the command line and in monitoring mode, file names are not displayed at all. Instead, “Trial Restriction” messages are displayed. We are aware of this feature until it is eliminated. You can get acquainted with how the monitoring mode works in principle and on trial. And it is possible to evaluate the diagnostic capabilities of the analyzer on standard Visual Studio projects. If after all this is not enough and you want to try to monitor the compilation in the case, and you do not have a license, then write to us - we will give a temporary key.