Per-project options in Visual Lint? - c++

I've used Visual Lint (as a frontend for PC-lint) in the past and somehow configured it to use a different options.lnt file for different projects. My recollection, which might be incorrect, is that it was configured to automatically pick up anything called "options.lnt" in any project's directory - i.e. I didn't have to configure this for each project individually.
So for example I might have two projects, ProjX and ProjY, and I might have different options.lnt files in each of them:
C:\MyProjects\ProjX\options.lnt
C:\MyProjects\ProjY\options.lnt
Possibly those might refer to certain sets of general options stored in other files; for example I have C:\MyProjects\Lint\options.lnt for very general things, and then more specific options files for things related to certain packages; for example I have C:\MyProjects\Lint\options_boost.lnt for use by projects that use Boost. So if ProjX uses Boost, C:\MyProjects\ProjX\options.lnt will contain (at least) the lines:
C:\MyProjects\Lint\options.lnt
C:\MyProjects\Lint\options_boost.lnt
Whereas perhaps ProjY doesn't use Boost, and so its options.lnt would have the "general" line, but not the Boost-specific line.
This was all working fine, but I've migrated to a new computer, and I can't seem to get it working again. When I run Visual Lint against ProjX, it shows messages that should be suppressed by (for example) entries in C:\MyProjects\Lint\options_boost.lnt.
I have gone into Visual Lint's "Tools / Options", and under the "Analysis" tab, I have set "Preferred Analysis method" to "Per project". I have the Professional edition, which I believe is required for this functionality. I am using version 5 (whereas the previous machine, on which this was working, was version 4).
Am I perhaps missing some additional configuration I need to set up in order to get Visual Lint to pay attention to the project's options file?

Answering my own question:
In Visual Lint, go to Tools / Options / PC-lint. In there, there's a "Configuration" field, containing the name of a *.lnt file (like C:\Lint\std.lnt) that applies to anything you do in PC-lint via Visual Lint. Edit that file to contain the line:
options.lnt
Without specifying a full path. That seems to make it pick up the copy of options.lnt from the project's directory, and that file can then contain the more specific lines as shown in the question, such as:
C:\MyProjects\Lint\options.lnt
C:\MyProjects\Lint\options_boost.lnt

Related

Visual Studio: how to control specific configuration parameters on student PCs?

Can anyone tell me how to control default configuration parameters in VS 2017 C++? The scenario is that we generate one sample PC with the software we want (Win10, VS2017, et cetera), and this image is cloned onto about 100 PCs in student CS labs.
The two specific things I would like to control are (1) use of precompiled headers and (2) message C4706 (= versus == in an if condition). There are some others, but these are at top of the list.
I know students could fix this themselves, but so many are confused in the first few weeks of an introductory programming class that I don't want to try that.
A search of MSDN has not been productive, but I probably am using the wrong search terms.
Thank you in advance!
You could also edit the default platform property pages found at \\AppData\Local\Microsoft\MSBuild\v4.0, Microsoft.Cpp.Win32.user.props and Microsoft.Cpp.x64.user.props
I'm not sure how you would automatically distribute those files but so long as you are using MSBuild as the build system anything in those files is picked up prior to project-specific settings.
There are two ways I can think of:
Change the default settings in property pages for each configuration
Create a custom project template with all the project settings necessary. This will only affect new projects created with this template. Also it will keep the default template intact and will probably allow students to experiment a bit more.
For enabling Precompiled header.
Right click your project->Properties->( a property pages window appears)Configuration Properties-> C/C++ -> Precompiled Headers -> (on the right side) Select Use(/Yu) by clicking Precompiled Header.
And for suppressing C4706, set compiler warning to level less than 4
Right click your project->Properties->( a property pages window appears)Configuration Properties-> C/C++ -> General ->Warning Level to less than 4
To retain the settings and share with others....
I do not have proper VS2017.... Can you try as said below.....
First export the existing project settings using
project(visual studio menu)->Export template.... continue and and save the template and make a note of the path....
usually by default the templates is saved in below path as a zip file.
C:\Users\<>\Documents\Visual Studio 2017\My Exported Templates
Now copy the zip file and and put it in
C:\Users\<>\Documents\Visual Studio 2017\Templates\ProjectTemplates\Visual C++ Project
Check if your template is automatically picked up.
If not open visual studio command prompt tool and run
devenv /installvstemplates.

Import Existing C++ Source Code into Visual Studio

I am trying to import an existing c++ application's source into visual studio to take advantage of some specific MS tools. However, after searching online and playing with visual studio, I cannot seem to find an easy way to import existing c++ source code into visual studio and keep it structurally intact.
The import capacity I did find flattens out the directories and puts them all into one project. Am I missing something?
(This is all unmanaged C++, and contains specific builds for win/unix)
With no project/solution loaded, in Visual Studio 2005 I see this menu item:
File > New Project From Existing Code...
After following the wizard, my problem is solved!
Switching the "Show All Files" button shows the complete hierarchy with all directories and files within.
If the New Project From Existing Code... option isn't available, you'll need to add it in Tools > Customize...
I am not aware of any general solution under the constraints given - specifically having to create many projects from a source tree.
The best option I see is actually creating the project files by some script.
Creating a single project manually (create empty project, then add the files),
Configure it as close as possible as desired (i.e. with precompiled headers, build configurations, etc.)
Use the .vcproj created as skeleton for the project files to be created
A very simple method would file list, project name etc. with "strange tokens", and fill them in with your generator. If you want to be the good guy, you can of course use some XML handling library.
Our experience: We actually don't store the .vcproj and .sln in the repository (git) anymore, but a python script that re-genrates them from the source tree, together with VS 2008 "property sheet templates" (or whatever they are called). This helps a lot making general adjustments.
The project generation script contains information about all the projects specialties (e.g. do they use MFC/ATL, will it create DLL or an EXE, files to exclude).
In addition, this script also contains dependencies, which feeds the actual build script.
This works quite well, the problems are minor: python requried in build systems, not forgetting to re-gen the project files, me having to learn some python to make adjustments to some projects.
#Michael Burr "How complex are the python scripts and whatever supporting 'templates' you might need?"
I honestly can't tell, since I gave the task to another dev (who picked python). The original task was to provide a build script, as the VS2008 solution build was not good enough for our needs, and the old batch file didn't support parallelization. .vcproj generation was added later. As I understand his script generates the .vcproj and .sln files from scratch, but pulls in all the settings from separate property sheets.
Pros:
Adding new configurations on the fly. Some of the projects already had six configurations, and planning for unicode support meant considering doubling them for a while. Some awkward tools still build as MBCS, so some libs do have 8 configs now. Configuring that from hand is a pain, now it just doesn't bother me anymore.
Global changes, e.g. moving around relative project paths, the folder for temp files and for final binaries until we found a solution we were happy with
Build Stability. Merging VC6 project files was a notable source of errors for various reasons, and VC9 project files didn't look better. Now things seem isolated better: compile/link settings in the property sheets, file handling in the script. Also, the script mostly lists variations from our default, ending up easier to read than a project file.
Generally: I don't see a big benefit when your projects are already set up, they are rather stable, and you don't have real issues. However, when moving into the unknown (for us: mostly VC6 -> VC9 and Unicode builds), the flexibility reduced the risk of experiments greatly.
Create a new empty solution and add your source code to it.
For example,
File>New>Project...
Visual C++>Win32>Win32 Console Application
Application Settings>
- Uncheck "Precompiled Header"
- Check "Empty Project"
Project is then created. To add existing code:
Project>Add Existing Item...>
- Select file(s) to add
Recompile, done!
In the "Solution Explorer" you can click on the "Show All Files" button to have Visual Studio display the files as they exist on the file system (directories and all).
In my opinion this is an imperfect workaround, but I believe it's the best available. I'm unaware of a plug-in, macro or other tool that'll import a directory into an actual project with folders that mirror the file system's.
I know this question is already marked correct, but I was able to import existing code into a project with Visual Studio 2008 by doing "File" -> "New Project from existing code". The directory structure of my code was retained.
You can always switch view from project menu
For eg. Project->Show All Files
The above will display the files in unformated raw file system order
Not sure of older versions but it works on VS 2010
I understand you, I have the same problem: many .cpp and .h files organized in many folders and subfolders with include paths written for this folder structure. The only way you can do to import this folder structure together with the source files is to use "Show All Files" and then right-click on folders and select "Import in Project". This works for me when I am using C-Sharp projects. But it does not work for my C++ Projects. I am still searching for a solution...

Should I add .vcxproj.filter files to source control?

While evaluating Visual Studio 2010 Beta 2, I see that in the converted directory, my vcproj files became vcxproj files. There are also vcxproj.filter files alongside each project which appear to contain a description of the folder structure (\Source Files, \Header Files, etc.).
Do you think these filter files should be kept per-user, or should they be shared across the whole dev group and checked into SCC?
My current thinking is to check them in, but I wonder if there are any reasons not to do that, or perhaps good reasons why I should definitely check them in.
The obvious benefit is that the folder structures will match if I'm looking at someone else's machine, but maybe they'd like to reorganize things logically?
We intentionally pulled the .filter. file information out of the .vcproj when we translated to the .vcxproj MSBuild format.
One reason is exactly what you pointed out, that the filters are purely a logical view, and different team members may want different views.
The other is that sometimes the build is set up to check the timestamp of the project file, and trigger a rebuild if it has changed - because that may mean there are different source files to build, or different settings, etc. I don't recall if we actually shipped with the build trigging that way, but the idea was that we did not want to trigger a rebuild simply because the filters changed, as they don't affect the build.
Previous versions of Visual Studio (at least versions 6.0 and 2008) store that information in their own project file (.dsp and .vcproj files respectively), which of course is good to add to SCC.
I cannot think of any reason to not include this .filter files in SCC
I just found that if you use Git you can mark .filter files to be treated as a union for merging to make it simpler. Just add the line:
*.vcxproj.filters merge=union
to your .gitattributes file.
See Using .gitattributes to avoid merge conflicts for more details.
It should not be added in case you use CMake (or similar build tools) to generate files like *.sln, *.vcxproj, *.vcxproj.filters etc., because this files may contain full path to your Project Folder and other only your computer's specific folders.

Building both DLL and static libs from the same project

I have a number of native C++ libraries (Win32, without MFC) compiling under Visual Studio 2005, and used in a number of solutions.
I'd like to be able to choose to compile and link them as either static libraries or DLLs, depending on the needs of the particular solution in which I'm using them.
What's the best way to do this? I've considered these approaches:
1. Multiple project files
Example: "foo_static.vcproj" vs "foo_dll.vcproj"
Pro: easy to generate for new libraries, not too much manual vcproj munging.
Con: settings, file lists, etc. in two places get out of sync too easily.
2. Single project file, multiple configurations
Example: "Debug | Win32" vs "Debug DLL | Win32", etc.
Pro: file lists are easier to keep in sync; compilation options are somewhat easier to keep in sync
Con: I build for both Win32 and Smart Device targets, so I already have multiple configurations; I don't want to make my combinatorial explosion worse ("Static library for FooPhone | WinMobile 6", "Dynamic library for FooPhone | WinMobile 6", "Static library for BarPda | WinMobile 6", etc.
Worse Con: VS 2005 has a bad habit of assuming that if you have a configuration defined for platform "Foo", then you really need it for all other platforms in your solution, and haphazardly inserts all permutations of configuration/platform configurations all over the affected vcproj files, whether valid or not. (Bug filed with MS; closed as WONTFIX.)
3. Single project file, selecting static or dynamic via vsprops files
Example: store the appropriate vcproj fragments in property sheet files, then apply the "FooApp Static Library" property sheet to config/platform combinations when you want static libs, and apply the "FooApp DLL" property sheet when you want DLLs.
Pros: This is what I really want to do!
Cons: It doesn't seem possible. It seems that the .vcproj attribute that switches between static and dynamic libraries (the ConfigurationType attribute of the Configuration element) isn't overrideable by the .vsprops file. Microsoft's published schema for these files lists only <Tool> and <UserMacro> elements.
EDIT: In case someone suggests it, I've also tried a more "clever" version of #3, in which I define a .vsprops containing a UserMacro called "ModuleConfigurationType" with a value of either "2" (DLL) or "4" (static library), and changed the configuration in the .vcproj to have ConfigurationType="$(ModuleConfigurationType)". Visual Studio silently and without warning removes the attribute and replaces it with ConfigurationType="1". So helpful!
Am I missing a better solution?
I may have missed something, but why can't you define the DLL project with no files, and just have it link the lib created by the other project?
And, with respect to settings, you can factor them out in vsprop files...
There is an easy way to create both static and dll lib versions in one project.
Create your dll project. Then do the following to it:
Simply create an nmake makefile or .bat file that runs the lib tool.
Basically, this is just this:
lib /NOLOGO /OUT:<your_lib_pathname> #<<
<list_all_of_your_obj_paths_here>
<<
Then, in your project, add a Post Build Event where the command just runs the .bat file (or nmake or perl). Then, you will always get both a dll and a static lib.
I'll refrain from denigrating visual studio for not allowing the tool for this to exist in a project just before Linker (in the tool flow).
I think the typical way this is done is choice 2 above. It is what I use and what I have seen done by a number of libraries and companies.
If you find it does not work for you then by all means use something else.
Good luck.
I prefer 2 configurations way.
Setup all common settings via 'All configurations' item in a project properties windows. After it separated settings. And it's done. Let's go coding.
Also there is very good feature named 'Batch build', which builds specified configurations by turn.
Multiple projects are the best way to go - this is the configuration i have most widely seen in umpteen no of projects that i have come across.
That said, it might be also possible to implement the third option by modifying your vcproj files on the fly from external tools(like a custom vbscript), that you could invoke from a make file. You can use shell variables to control the behavior of the tool.
Note that you should still use use visual studio to make the build, the makefile should only launch your external tool if required to make the mods and then follow that by the actual build command
I use Visual Studio 6.0 (Still) due to issues that are preventing us from Migrating to VS2005 or newer. Rebuilding causes severe issues (everything breaks)... so many of us are considering lobbying a migration to GnuC++ moving forward in a structured way to eventually get us off of licensed Visual Studio products and onto Eclipse and Linux.
In Unix/Linux it is easy to build for all configurations.. so I can't believe what a time and productivity sink it is to try and accomplish the same task in Visual Studio. For VS6.0 I have so far found that only having two separate projects seems to be workable. I haven't yet tried the multiple configuration technique, but will see if it works in the older VS6.0.
Why not go for version 1 and generate the second set of project files from the first using a script or something. That way you know that the differences are JUST the pieces required to build a dll or static lib.

Complex builds in Visual Studio

I have a few things that I cannot find a good way to perform in Visual Studio:
Pre-build step invokes a code generator that generates some source files which are later compiled. This can be solved to a limited extent by adding blank files to the project (which are later replaced with real generated files), but it does not work if I don't know names and/or the number of auto-generated source files. I can easily solve it in GNU make using $(wildcard generated/*.c). How can I do something similar with Visual Studio?
Can I prevent pre-build/post-build event running if the files do not need to be modified ("make" behaviour)? The current workaround is to write a wrapper script that will check timestamps for me, which works, but is a bit clunky.
What is a good way to locate external libraries and headers installed outside of VS? In *nix case, they would normally be installed in the system paths, or located with autoconf. I suppose I can specify paths with user-defined macros in project settings, but where is a good place to put these macros so they can be easily found and adjusted?
Just to be clear, I am aware that better Windows build systems exist (CMake, SCons), but they usually generate VS project files themselves, and I need to integrate this project into existing VS build system, so it is desirable that I have just plain VS project files, not generated ones.
If you need make behavior and are used to it, you can create visual studio makefile projects and include them in your project.
If you want less clunky, you can write visual studio macros and custom build events and tie them to specific build callbacks / hooks.
You can try something like workspacewhiz which will let you setup environment variables for your project, in a file format that can be checked in. Then users can alter them locally.
I've gone through this exact problem and I did get it working using Custom Build Rules.
But it was always a pain and worked poorly. I abandoned visual studio and went with a Makefile system using cygwin. Much better now.
cl.exe is the name of the VS compiler.
Update: I recently switched to using cmake, which comes with its own problems, and cmake can generate a visual studio solution. This seems to work well.
Specifically for #3, I use property pages to designate 3rd party library location settings (include paths, link paths, etc.). You can use User Macros from a parent or higher level property sheet to designate the starting point for the libraries themselves (if they are in a common root location), and then define individual sheets for each library using the base path macro. It's not automatic, but it is easy to maintain, and every developer can have a different root directory if necessary (it is in our environment).
One downside of this approach is that the include paths constructed this way are not included in the search paths for Visual Studio (unless you duplicate the definitions in the Projects and Directories settings for VS). I spoke to some MS people at PDC08 about getting this fixed for VS2010, and improving the interface in general, but no solid promises from them.
(1). I don't know a simple answer to this, but there are workarounds:
1a. If content of generated files does not clash (i.e. there is no common static identifiers etc.), you can add to the project a single file, such as AllGeneratedFiles.c, and modify your generator to append a #include "generated/file.c" to this file when it produces generated/file.c.
1b. Or you can create a separate makefile-based project for generated files and build them using nmake.
(2). Use a custom build rule instead of post-build event. You can add a custom build rule by right-clicking on the project name in the Solution Explorer and selecting Custom Build Rules.
(3). There is no standard way of doing this; it has to be defined on a per-project basis. One approach is to use environment variables to locate external dependencies. You can then use those environment variables in project properties. Add a readme.txt describing required tools and libraries and corresponding environment variables which the user has to set, and it should be easy enough for anyone to set up.
Depending on exactly what you are trying to do, you can sometimes have some luck with using a custom build step and setting your dependencies properly. It may be helpful to put all the generated code into its own project and then have your main project depend on it.