Problem: I have a large Visual C++ project that I'm trying to migrate to Visual Studio 2010. It's a huge mix of stuff from various sources and of various ages. I'm getting problems because something is including both winsock.h and winsock2.h.
Question: What tools and techniques are there for displaying the #include hierarchy for a Visual Studio C++ source file?
I know about cl /P for getting the preprocessor output, but that doesn't clearly show which file includes which other files (and in this case the /P output is 376,932 lines long 8-)
In a perfect world I'd like a hierarchical display of which files include which other files, along with line numbers so I can jump into the sources:
source.cpp(1)
windows.h(100)
winsock.h
some_other_thing.h(1234)
winsock2.h
There is a setting:
Project Settings -> Configuration Properties -> C/C++ -> Advanced -> Show Includes
that will generate the tree. It maps to the compiler switch /showIncludes
The compiler also supports a /showIncludes switch -- it doesn't give you line numbers, but can give a pretty comprehensive view of which includes come from where.
It's under Project Settings -> Configuration Properties -> C/C++ -> Advanced -> Show Includes.
We have found IncludeManager to be a very powerful tool. It is not free (but not expensive) out of development and free now. It only supports Visual Studio 2005 through 2013.
It allowed us to get a grip of our Include issues and drop our compile time from 50 minutes to 8 minutes by pruning out large chunks of includes we weren't using.
Not as good as gcc's hierarchical include feature, which shows the direct-line inclusion hierarchy in the case of an error. The "show includes" option in VS shows everything, which is overkill when debugging hierarchical include file problems.
There is now a plugin for Visual Studio called IncludeToolbox. It can list your dependent includes and do more things like a random remove and compile to see if that include was required.
Try redhat Source-Navigator for a more graphical solution.
I use Doxygen and GraphViz for class hierarchy graphics and a dependency tree in text for those.
Doxygen: Class Hierarchy
Doxygen diagrams: include hierarchy (classes)
Install both. Make sure to select GraphViz as the tool to generate the hierarchy diagrams. Select "Use dot tool from the GraphVix package".
Also make sure to include the binary directory from GraphViz into your PATH environment variable.
IncludeFinder is a good 3rd-party, FOSS tool. You can export results to XML, which will include data on number of occurrences and line numbers.
cl /P should show you the line numbers, such that you can tell the context of where a header file is being included from.
If you grep out the lines with ...
grep "^#line" file.i
... then you should have a pretty clean indication of what files were encountered in order by the preprocessor.
If it's a one off incident this should be a pretty quick diagnostic.
Related
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.
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...
I have checked in buid directory and have not found makefile there. How does Visual Studio 2008 buid the project? Does it use makefile?
The NMAKE utility has been distributed with Visual C++ since back when it was called Microsoft C/C++ Optimizing Compiler, and is very similar to Unix make. Previous versions of the IDE actually used NMAKE makefiles, but this isn't true anymore. You can write NMAKE makefiles yourself if you want, but it sounds like you want to know what the IDE does.
Starting with VS2010, the build system changes to MSBUILD, which bertelmonster mentioned. But not in VS2008.
In VC++ 6.0, C++ projects have their own build engine integrated into msdev.exe.
In VS2002 - VS2008, it's a separate tool, VCBUILD. But you can still invoke it via the main IDE, devenv.exe, see the /BUILD option, and devenv is the best way if you have inter-project dependencies in your solution.
VS9 doesn't use makefiles by default the way Linux-flavored IDEs might. Instead, VisualStudio uses 'solution' and 'project' files. A Project file (*.vcproj for C/C++ projects) is basically a replacement for makefiles, and contains instructions, compiler directives, flags and everything else needed to compile a single 'project'. In this parlance, a project is a single output file, such as an EXE or DLL. But this same mechanism can be used to produce any kind of output, including TLBs, text files, widgets and ice cream cones (if your machine has the capable hardware :) )
A 'solution' is a collection of projects, and the solution file (*.sln) contains lists of projects needed to build an entire application suite, typically. It also contains dependancy information, so that the projects are built in the correct orders.
Solution and project files are human-readable text, but in the VS world you would virtually never want to edit these files yourself the way you would tweak a makefile by hand. Instead, you would use the IDE to change compiler flags, preprocessor directives, output directories, and all the rest.
That is how VS works by default, but VS is also capable of using makefiles in much the same way as Linux-flavored IDEs. It still uses solution files in this case, so you can mix projects that use makefiles with projects that use project files within the same solution. The VS IDE is actually quite powerful in this regard, and gives you the ability to do pretty much whatever you want. This power however comes with a price -- with so many features and capabilities available in the IDE, it can be rather complex and takes what you might think is an unwarranted ammount of user brainpower to fully understand.
If you want to create a makefile project, you can do so by doing File>New>Project... and then selecting Makefile Project from the main Visual C++ list of project templates.
Is there some way to externalize the paths of libraries that are used in the compilation process on Visual Studio 2008? Like, *.properties files?
My goal is to define "variables" referencing locations to headers files and libraries, like *.properties files are used in the Ant build system for Java.
I think you're looking for .vsprops files. They're comparable to the *.properties files.
Environment Variables?
All the $(xyz) replacements allowed in the propertier are, and you are allowed to "bring your own".
They are normally inherited from the parent process, so you can set them
for the machine / user in the system settings (usually inherited via explorer)
in a batch file that sets them before running devenv.exe
in an addin like SolutionBuildEnvironment to read them from a project file
I don't know how Ant works, but for your static libraries and headers you can edit the .vcproj file. These are XML files in fact. Libraries go in the VCLinkerTool tool tag, in AdditionalDependencies
<Tool
Name="VCLinkerTool"
AdditionalOptions=" /subsystem:windowsce,5.01"
AdditionalDependencies="iphlpapi.lib commctrl.lib coredll.lib"
/>
Additional header paths are defined in the VCCLCompilerTool tool tag, in AdditionalIncludeDirectories
<Tool
Name="VCCLCompilerTool"
Optimization="0"
AdditionalIncludeDirectories="dev\mydir"
PreprocessorDefinitions="WIN32;_DEBUG;_CONSOLE"
/>
Be careful, there is one such section for each build configuration.
Is this what you are looking for?
Edit : the .vsprops suggested by MSalters are more powerful; you can define additional dependencies and libraries in them an make your projects inherit these properties. Well I learned something useful today!
If you're referring to influencing the location of #includes, Project properties|Configuration Properties|C/C++/Additional Include Directories is the ticket. There is also project properties|Common Properties|Additional reference search paths.
If your question is how do I parameterize stuff in a VCProj file like I would in Ant, the answer is that in VS2010 VC projects are[/can?] be MSBuild-based whereas VS2008 vcproj files are a proprietary XML based format [but as the other answers say, they have an analogous properties capability].
In the absence of more info, I'm pretty sure the standard approach for what you're doing is to add your search paths a la the first or second paragraph.
You can use a build system like CMake. You give CMake a high-level description of your project, and it spits out the necessary files to get your project to build correctly via another tool (e.g. Visual Studio's IDE, or a Unix-style makefile).
Paths: You can use CMake's INCLUDE_DIRECTORIES() and LINK_DIRECTORIES() commands in the CMakeList.txt configuration file to specify these paths. CMake has variables which describe both aspects of your environment (many of which can be autodiscovered, e.g. CMAKE_C_COMPILER which is the command to run your C compiler) plus any options you wish to allow the user to specify directly. All variables are stored in a separate plain text configuration file, CMakeCache.txt, that can be edited in a text editor or using a special GUI configuration tool.
CMake has many other features, like the ability to autodiscover the locations of many useful libraries, and to produce customised source/header files from "template" files containing CMake directives using the CONFIGURE_FILE() command.
Advantages:
Highly portable across common environments (e.g. it can produce solution files for several versions of MS Visual C++, as well as makefiles for Unix (e.g. Linux) systems).
Used by several large multiplatform projects (e.g. KDE)
Very simple to set up simple projects
I've found the dependency checking system to be rock-solid -- e.g. it knows to rebuild if you change compiler options (unlike naive use of make for example)
Disadvantages:
Ugly, primitive syntax
Documentation quality varies (e.g. it's sometimes hard to tell exactly what properties affect any given object)
Some time investment involved
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.