To automate C++ code quality analysis in our company, I've been asked to integrate Cppcheck tool with our SonarQube server (through the C++ Community plugin).
For the C++ part of our main product, in Visual Studio, we have a dozen of solutions, with almost a hundred of projects within each solution.
We use standard inherited property page macros like $(SolutionDir) and $(ProjectDir), and define our own custom (user-defined) macros as well (via Property Manager).
I'm currently writing Windows command line batch scripts to perform static code analysis separately on each solution. The idea is to run Cppcheck with an option like --project="solution_name.sln" and then run SonarQube Scanner to parse the generated XML output.
But there's a problem. It seems that Cppcheck doesn't recognize these $(SolutionDir) macros during include path resolution. (When run with --check-config option, it complains about missing include files.)
Unfortunately it turns out I even cannot supply additional include paths for a solution because the -I and --includes-file options are ignored when --project is specified.
How is Cppcheck supposed to be used with Visual Studio projects in an automated environment? I'm talking about command line interface (to be used on server side), not about interactive plugins (as used locally on developers' machines).
One possible way would be to create a Python script to preprocess the hundreds of project (*.vcxproj) files, replacing all these macros with real paths (each time after checking out from SVN and before executing Cppcheck). Or is there a proper way to make Cppcheck recognize Visual Studio macros?
Yes the --project is supposed to work. It's just that --project is a very new feature.
I would like to have a simple solution so I can reproduce easily.. Could you create some simple solution with such configuration? no real code is needed. I think a cpp file with just a #include and then an empty header might be enough. Configure it so that Visual Studio finds the header but Cppcheck doesn't.
Please attach it to the ticket orbitcowboy created.
Related
I use Xorax IncrediBuild to build Visual Studio 2013 (or later) solutions and projects, they're mostly .vcxproj with a bunch of .csproj ones.
It took me a little bit of digging, but I've learned that:
When IncrediBuild is used with the regular Visual Studio, it uses the Devenv.exe by default.
Since version 5.0, BuildConsole.exe supports a new switch: /UseMSBuild to specifically instruct IncrediBuild to use MSBuild's build engine instead of the default Visual Studio's DevEnv.
So, in case of Visual Studio projects, there are two modes available:
BuildConsole.exe MyProj.vcxproj which uses DevEnv.exe
BuildConsole.exe MyProj.vcxproj /usemsbuild which uses MSBuild.exe
I'd like to learn if there are any differences between using the two engines.
I have made some tests and observed that:
IncrediBuild "Initializing..." phase takes slightly longer in case of DevEnv.exe.
BuildConsole.exe generates different output, obviously.
No (or insignificant) difference in build performance.
In case of building individual C/C++ native projects (.vcxproj) as well as whole solutions (.sln), what are advantages and disadvantages of using DevEnv.exe versus MSBuild.exe?
** disclaimer: I work at IncrediBuild **
We've determined together with Microsoft that in order to get builds that behave in the same manner as building from within Visual Studio (without IncrediBuild), DevEnv should be used. MSBuild executes builds in a slightly different manner than VS both in the build output it produces and in the way it behaves when executing custom steps and some other minor things. If a user wants IncrediBuild builds to behave in the same manner as he is used to when building from Visual Studio, the default way should be used (IncrediBuild executing DevEnv). If a user is used to execute his builds using MSBuild, whether from the command line or through TFS, the UseMSBuild switch should be used. We wanted to allow users to choose the way they would like IncrediBuild to work depending on the way they are used to do that, same as Microsoft supporting both DevEnv and MSBuild.
Additional comments:
The initialization stage is indeed longer when using Devenv, since devenv loads and parses the solution and .vcxproj files in a different manner than msbuild. The more Projects a solution has – the longer this phase should take. The increase of time it takes this phase to complete usually greatly offset by the speed increase in the actual build time – when building several projects at the same time.
Devenv is highly recommended for our Predicted Execution feature which can provide up to 20% of additional build acceleration due to the above way of work which would be not possible using MSBuild.
Microsoft is pretty explicit about it:
For build-related tasks, it is now recommended that you use MSBuild instead of devenv. For more information, see MSBuild Command Line Reference.
A note in the Devenv documentation since VS2010, the first version of VS that started supporting building C++ projects with MSBuild and also changed the default project file extension from .vcproj to vcxproj.
The wisdom of this kind of advice can only be inferred when they are not explicit about it. One you ready saw, Devenv.exe is a pretty heavy process with many DLL dependencies, it takes a while to get going. Another you could fret about with the way you are doing it now, original guidance was to use Devenv.com instead of Devenv.exe. Those dependencies are also troublemakers, the kind that tend to get in the way or just plain fall over when Devenv.exe runs in an unusual runtime environment like a service. Sample story-from-hell is this Q+A, three answers and none look correct. There are others.
Plain advice is to use the recommended way.
If I run a c++ project/solution, in Visual Studio, with a command line option "--xx", how can I do the exact same thing from TeamCity ?
I have searched and have been unable to find any option.
The one thing that looks like "Command line parameters" is actually designated for MSBuild.
I have to run the solution - and not just the executable generated by the solution.
Thank you.
Your Visual Studio build is executed using MSBuild on the server, the name may be a little confusing, but the parameters should function in the same way using that MSBuild parameter box as passing them to visual studio would be.
if there are issues getting this to work using that parameters box, we will need some more information about the commands you need to run and the behaviour you need.
Edit following questioner's comment
The problem in actuality here is that Visual Studio builds don't really exist in TeamCity, visual studio build is actually just going to run MsBuild against your visual studio solution, which, in terms of Google Test, is sufficiently different to cause your problems.
To resolve this, you are probably going to have to change your build runner to just be an MsBuild script which builds your solution and runs the Google tests. thankfully, the internet provides:
http://code.google.com/p/msbuildteamcitytasks/wiki/RunGoogleTests
The above is some MsBuild tasks which claim to integrate GoogleTest results completely with TeamCity, doing all the leg work for you in that regard. The result of this is that you only need a very brief build script calling MsBuild on your solution, followed by calling that MsBuild Task as required. I cant confirm how well they work or how easy they are to set up as I haven't used them, but the documentation on the page implies it should be reasonably easy to put together.
below is a snippet of MsBuild that will build your solution(s)
<MSBuild Projects="#(BuildProjects)" Targets="Rebuild" BuildInParallel="true" Properties="Configuration=Debug;Platform=$(Platform)">
<Output ItemName="DebugOutputs" TaskParameter="TargetOutputs"/>
</MSBuild>
where each $() variable is a system property in your TeamCity configuration #(BuildProjects) is a list of solutions generated using this:
<ItemGroup>
<BuildProjects Include="$(WorkingArea)\**\*.sln" />
</ItemGroup>
you can of course hard code any and all of these variables, or change parameters as required, but this example will give you some freedom to reuse the script on other projects (its not a full script, there's some extra structure stuff to go around the outside).
you can of course build in further functionality to the script as required, or leave it as simple as possible to make it easy to understand.
there is further documentation on MsBuild scripts are available from these locations:
http://www.universalthread.com/ViewPageArticle.aspx?ID=61
http://codingcockerel.co.uk/2008/04/15/automating-the-build-with-msbuild/
http://www.codeproject.com/Articles/12985/Practical-NET2-and-C-2-An-introduction-to-MSBuild
I'm sure there's plenty more out there if you need it.
Well, In TeamCity (I am using version 6.5.x), When you add a new Build Step, select the Build runner as Visual Studio (sln) or Visual Studio 2003 as per your requirement and there you'll get the option to pass command line parameters.
What Version of TeamCity do you use?
Is it possible that I can just compile all CPP files under a project and without linking etc. the project?
The only way I know to do this is by specify the /c switch when you compile the code. Unfortunately, this option is not available from within the Visual Studio development environment, so you'll need to build your code on the command line by calling cl.exe directly. To make things easy on yourself, use the Visual Studio Command Prompt to do so.
Not sure if it's possible to get MSBuild to do this, the documentation is unclear whether the limitation is Visual Studio itself or if it's a limitation of MSBuild. I haven't actually tried for myself.
Alternatively, you can build individual source files from within the IDE by pressing Ctrl+F7 (at least, assuming the default C++ development settings). If that fails, it's also available as the "Compile" option located in the "Build" menu.
I'm not sure whether this will do what you need, but may be worth a try: create a project for an executable (rather than a library) and include all cpp files in it. Add a main() function that just returns zero. Set the C++ optimisation option to 'optimise references' (/OPT:REF). This may just compile all the cpp files but effectively ignore them during the link stage since none of them are referenced by the application.
You don't say why you need to do this - is it because linking takes a huge amount of time?
Where can I find the build script -all the list of tools used to build and link the assemlies like al.exe etc.-that BUILDS, REBUILDS the visual-Studio solutions?
MSBuild (the build engine for Visual Studio) uses a model where the tool(s) used for an action are dictated by the project file being built. Thus your list of tools will vary based on the types of projects you are building. The easiest way to find out the list of tools being used for a build of any given solution would be to turn on a more detailed logging level (detailed or diag) for MSBuild via Tools->Options->Projects & Solutions->Build & Run in Visual Studio and then parse/investigate the build output for an indication of the tools currently invoked by the Build Targets.
As Nick Nieslanik has said in his answer, the actual toolset will vary based on the project type (and target programming language), maybe even the selected .NET framework version.
To have single view on all definitions, properties, targets, etc. used by MSBuild, you could generate and review a fully preprocessed project file (only available with MSBuild 4.0 or newer).
From msbuild.exe /? output:
/preprocess[:file]
Creates a single, aggregated project file by
inlining all the files that would be imported during a
build, with their boundaries marked. This can be
useful for figuring out what files are being imported
and from where, and what they will contribute to
the build. By default the output is written to
the console window. If the path to an output file
is provided that will be used instead.
(Short form: /pp)
Example:
/pp:out.txt
Example:
msbuild.exe myproj.csproj /pp:out.xml
In this case out.xml is basically a self-contained file that has all the Import-ed project files inline so you can easily search and browse them.
In each project (in this case a c# csproj) file is a link to the msbuild used by msbuild/visual studio to build.
e.g. <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
This target links to the internal files used.
I am new to Visual Studio Extensibility and want to make an addin/extension which shall do the following:
It should read all the files with a specific file extension (assume "*.ump").
It should process the text/code/whatever in the files.
It should create new Class/Code file with some code in it. [The code will be produced in step 2, just need to know how to do it?]
Yet, I have been racking my brains through extensibility, saw the single file generators .... and addins which go through ProjectItems and can detect the file extension,
BUT I HAVE NOT BEEN ABLE TO FIND a complete tutorial, guide or explanation as to how or what to do!!
Please help...
You don't want to read all files with a specific file extension in Visual C++ project nor standard Visual C# project. You may do that with hand-made MSBuild project (included in the solution).
In Visual C++ projects, there is a way to define custom tools. They are run as separate processes, so you can implement them in anything you want. Studio will ask you whether you want to define a tool (they are defined in special xml files; studio has dialog for editing them) when you add a file with extension unknown to it. In Visual C# projects, just manually write a MSBuild tasks and insert them into the project.
Do whatever you want. IIRC the generated files will have to be included in the project though. Well, for MSBuild, just tweak the project to your heart's desire, but in Visual C++ they have to.
You can combine MSBuild (csproj,vbproj) and VisualC++ projects in a single solution, so I recommend using separate.
If you ever find out you need to compile for different target where you can't use Visual Studio, you'll be glad that you have stand-alone tool you were just calling from Studio and not something that embeds in it.