PVS-Studio Now Supports Any Build System under Windows and Any Compiler. Easy and Right Out of the Box.
0 likes•256 views
PVS-Studio now supports any build system and C/C++ compiler on Windows, allowing for automatic source file analysis by monitoring compiler calls. Users can utilize both a graphic interface and command line techniques to engage the monitoring tool and analyze projects, addressing previous limitations with certain build systems. However, users should be mindful of potential issues with simultaneous build processes and precompiled headers during monitoring.
PVS-Studio Now Supports Any Build System under Windows and Any Compiler. Easy and Right Out of the Box.
- 1. PVS-Studio Now Supports Any Build System under Windows and Any Compiler. Easy and Right Out of the Box. Author: Evgeniy Ryzhkov Date: 28.03.2014 We're currently preparing a bomb in PVS-Studio! The next PVS-Studio version 5.15 will be able to analyze projects built by absolutely any build system: Makefile, Visual Studio Project, user-made build systems based on Python, Bash or whatever else... It will allow you to simply "watch" compiler calls and collect all the necessary information to run the analyzer in automatic mode. Moreover, it works with any (sensible) C/C++ compiler under Windows. Want to know more? The working principles and the limitations of the Visual Studio plugin PVS-Studio was originally developed as a plugin for Microsoft Visual C++. Interaction between the tool and the development environment is manifested in two aspects: first, tool integration with the user interface, for it is more convenient to work with it from the environment you are used to; second, collecting file compilation parameters for a correct analysis. Let me remind the working principles of code analyzers (PVS-Studio in particular) to those who are not quite familiar with them. Before you can carry out an analysis of source files, you need to preprocess them, i.e. expand all the #include's and #define's. This is first of all necessary for the analyzer to know additional information about the data types used in the code. Until recently, the PVS-Studio plugin used to collect compilation parameters with the help of Visual Studio's API and run preprocessing automatically. Now we have learned how to track compilation parameters when the compiler is called and "reproduce" this call with the "perform preprocessing" switch – and only then call
- 2. the analyzer itself. It doesn't make any difference for the plugin, and it still retains the original mechanism. However, this mechanism couldn't be used with certain projects earlier (even some native Visual C++ projects). What are these cases? First, the cases when you have a Makefile-project built, for example, with nmake. In this case, Visual Studio's API didn't allow the plugin to get the compilation parameters and call the preprocessor. True, you could embed a PVS-Studio's call into Makefile, but let's admit that it is far from an elegant solution. We do have users who handle PVS-Studio this way, of course, but most were scared off by it. Second, when you have a self-made build system that calls the compiler from scripts, it only theoretically looks like Makefile. In practice, however, it is usually only the author of this system who can modify it, and he is not always easily accessible, so trying PVS-Studio on such a project may appear almost impossible. In other words, it was not a rare problem when you had a project well compilable by Visual C++ and you felt like trying PVS-Studio on it but could not do this, and your zest gradually grew weaker and weaker... How have we solved it? We have developed a special utility to monitor compiler calls. It works with all the basic compilers under Windows, but we mainly focused on Visual C++ users, as usual. The monitoring tool simply taps all the compiler calls and then launches the compiler once again with the "perform file preprocessing" parameter. After that, it calls the analyzer. The nicest thing is that the entire procedure is absolutely transparent for the user and anyone can do it. Moreover, we offer two different techniques to work with this mechanism. Technique 1 – Monitoring through the graphic interface Imagine that you have got access to Unreal Engine 4's source files. You open the solution in Visual Studio and see an nmake-based project which can't be checked by the PVS-Studio plugin. No problem. You just need to do the following: 1. Run PVS-Studio Standalone. 2. Click "Compiler Monitoring" and choose the x64 platform for monitoring, for you want to build a 64- bit version of Unreal Engine 4.
- 3. 3. Click "Start Monitoring" to turn on the compiler call monitoring mode. 4. Now you switch to Visual Studio and click Build to start building the project. While the build is running, you will see the status in the monitoring window indicating that compiler calls are being tapped. Notice that it is the number of tapped calls which is indicated there, not the number of source files. The reason is that the compiler is often launched with several files as its arguments, so the number of compiler calls is less than or equal to the number of files. 5. Once Visual Studio is finished with the build, click Stop Monitoring. After that, PVS-Studio will be launched. The files will be preprocessed and analyzed, and the diagnostic messages will be displayed in PVS-Studio Standalone's window. You can start working with them from there right away. However, I recommend that you wait until the analysis is over, save the analysis report as the UE4.plog file, then close PVS-Studio Standalone, open the UE4.plog file from within the Visual Studio environment through the PVS-Studio menu and handle the results from there. Why? Because you will be able to use IntelliSense inside Visual Studio, which will make it much easier to navigate through the code, track macros' values, search for variable declarations, and so on. You can also do it all from PVS-Studio Standalone of course, but let's be honest – our tool is far not as convenient as Visual Studio yet. This simple technique will allow you to easily check projects exploiting the monitoring graphic interface in PVS-Studio. But sometimes it may be more convenient to launch monitoring from the command line. The next section will tell you how to do that. Technique 2 – Monitoring through the command line interface The graphic interface is not always convenient for monitoring. Imagine you want to check Qt 5.2. To do this, we need to download the distribution package in the archive and unpack it. Then we launch Visual Studio 2012 Command Promt (to set up the environment correctly), go to the folder with Qt and do the following: 1. Turn on the monitoring mode: "C:Program Files (x86)PVS-StudioCLMonitor.exe" monitor The program will terminate right away but it will leave a "tracking module" running in background. 2. Run configure.exe – this is a program from the Qt package which prepares a build script. 3. Run nmake – and now settle back into your chair waiting for the Qt to finish with the build. 4. Once it is done, you need to tell the monitoring module to stop tapping and start analysis (and save the results into a log file for the Win32 platform): "C:Program Files (x86)PVS-StudioCLMonitor.exe" analyze C:Qt5.plog Win32 5. Once the analysis is over, the report will be saved into a log file. I do not recommend you to handle the log directly. It is better to open it in PVS-Studio Standalone as it is much more convenient to view and handle it from there. As you can see, checking projects built by any build system from the command line is as easy as through the user interface – the algorithm includes the same 5 simple steps.
- 4. Known issues and limitations We haven't revealed (yet?) any fundamental problems in the monitoring mechanism, but there are certain nuances you should know about. First, the monitoring module taps every single compiler call. It means that if you run several different build processes at once, each of them will be tapped – and analyzed. That is, you will get a mess of analysis results for the project you need and some wrong project. Keep that in mind and be sure not to run any other build processes while the monitoring module is active. Second, you may sometimes face subtle issues with precompiled headers. It is not a rare thing when the path to the precompiled headers is absent from the list of include folders. While the compiler can find these headers, the preprocessor (which is a part of the compiler!) cannot. The solution is a simple one – you just need to explicitly specify the path to certain include files in the list of include folders. Trial Mode And finally, a small bug in the butter. PVS-Studio has a trial mode which sets a limited number of clicks you can make in the list of diagnostic messages. However, when using PVS-Studio in the monitoring mode from the command line, file names are not shown at all. Instead, the messages "Trial Restriction" are displayed. However, you can still study the compiler monitoring while in the trial mode by using the PVS-Studio Standalone UI application (the 'Tools -> Analyze your files..' menu item).