I am trying to compile and build a project(s) in visual studio and I started looking into compiling with the /Wall option which gives all warnings.
I am wondering iof there is a way to run this only on those files I am interested in, since currently I get a million warnings on files i have no ability or desire to change.
In the Solution Explorer select the files you want all warnings for, right click and select Properties. From there you can adjust whatever compiler settings you want to for those files, just about like you would for the entire project.
Another approach that can work is to use the #pragma warning( ... ) modifiers.
This lets you controls specific warnings as well as the overall setting. See the documentation at http://msdn.microsoft.com/en-us/library/2c8f766e(v=vs.80).aspx
If a library or subproject causes a problem then you might be able to turn off warnings for it in a single place.
Modifying the project file for subsets of your files can get very messy very quickly, especially if you have multiple architectures and targets (debug, release, ...)
I prefer to modify the project files by hand in a text editor for this type of change so I am sure that everything is happening as expected.
If there is a Makefile (or equivalent) for your part of the project (e.g. a directory), then you may be able to add the the /Wall warning flag only for that part
WARNING_FLAGS += /Wall
(It still is not per file, but this may be more manageable.)
Another option is to put all the warning messages and filter (e.g. grep) for the file names you are interested.
Related
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
I'm working with a very old and large VC6++ project and it's all messed up. There are unused files and folders everywhere, copies of folders and it's just a mess to clean it up by hand in its current state.
It will be done eventually, but is there any simple way to check what files and folders are used when it does a clean compile?
The project settings doesnt help me at all because it simply uses copies of folders and additional include directories.
Any suggestions?
Well, if you want to parse the compiler output you can get which files are actually used. I also find this when googling around, you might want to try (I haven't tried it myself). My way would be to clean the build, list all source files, build, and for each source find its corresponding .obj. The ones without .obj are not used. Note that this only works for source files, unused header files stay undetected.
VC6 will produce a makefile for you:
http://msdn.microsoft.com/en-us/library/aa233950%28v=vs.60%29.aspx
You can use the generated makefile (and the associated .dep file) as a starting point and edit it down to the list of files that get used in a build.
This will let you see the header files that the project depends on in addition to the .c/.cpp/.lib files that might show in the build log. One thing to keep in mind is that you'll probably also want to make sure you track the .dsw and .dsp workspace and project files.
If you're a bit adventurous, you might be able to convince the makefile to actually copy the source files to some other location for you with an appropriate override of the certain macros and/or dependencies. But that would probably be more trouble than it's worth for a one-time effort.
Finally, there's a commercial product, CopyWiz by Kinook Software, that seems to have features that might do what you're looking for (and it supports VC++ 6). Note: I'm not sure if it will do what you want, but it may be worth a look.
Yes. Run Process Monitor from SysInternals. It can capture all file system events and filter them based on the path and other factors.
So, set the filter to the root of your source tree, only succesfull file reads (VC looks for headers in many places), and build your project. You'll probably still see several thousand events. So, save them to file, sort by path, and remove duplicate paths (headers especially will have many duplicate entries)
I want the compiler to run preprocessing, generate all the .i files like it normally does if I just use the "generate preprocessed file" option, and then run an external tool, wait for it to complete, and then go on with the compilation of those .i files (which by now can be modified of course).
If that is not possible, is there a way to run an external tool on every file that is being compiled before preprocessing and compilation? (Would probably be a hell to debug in environment like that, but still).
If there is no option like that, could this even be done at all? I mean, does the compiler even use those .i files, or are they just output for the user somehow?
Basically, is there any way to automatically tamper with the source before it is compiled, but without modifying the actual files?
Just for refs: I am trying to think of a smart way to obfuscate all the strings with minimum modification of the source.
Yes, you'd simply update your build system to have a preprocess step, obfuscate step, then compile-to-obj step. By default, most build systems merely merge all those to one step (and skip the obfuscate step). Should be no big deal with any "real" build system like Scons, waf, or even Make.
If you're using Visual Studio, then it is a bit more work. Microsoft wants you to write your build operations in MSBuild, and that's quite a bit of work, IMHO. It's not easy because MSVS is principally an IDE for iterative development, and NOT intended to be a build tool. It's not, and will never be, a build tool (even though it happens to do "build things", but only standard and very simple "build things"). But, you can still use the IDE with a different build tool. For example, we use Scons for our build, and it generates MSVS *.sln and *.vcproj files, and those files merely build with Scons (but all the files are edited in the MSVS IDE).
The simple answer: Your question is very simply a build-operations problem. It should be very straight-forward with any non-"toy" build system.
The distcc (distributed build tool) effectively preprocesses all files locally, then sends the *.i to remote compilers (that do not even need headers installed), and then ships back the *.obj. So, what you're talking about is pretty straight-forward.
Let x.cpp be your file you want to preprocess.
Set the compiler option to generate preprocessed output for x.cpp, let it be x.i.
Add the x.i to the project and set the "custom build tool" in the properties. Set the "output files" to x.preprocessed.cpp.
Add x.preprocessed.cpp to the project.
See msdn for details.
You should be able to perform a "Pre-Build Event" and plug in any external tools there. In VS200x it's under Configuration Properties -> Build Events -> Pre-Build Events.
Just use a decent build system. SCons, waf, or something else if you won't like those two.
You could use a make file to generate the .i files first, run your processing on them, then compile them.
So I have main.cpp and main2.cpp with int main in each. I want to get 2 exes out of it. Is it possible and what would be instruction to create such project?
Nope, Visual Studio's project model is rigidly built around the assumption that "one project generates one output".
If you need two executables, you have to create two projects. You can keep them in the same solution to make things easier for yourself, but they have to be separate projects.
Edit
Ok, as other answers have pointed out, it can of course be done, if you're desperate. You can add a custom build step, which does anything you like, including building another executable. (However, the build system won't understand that this file should be considered project output, and so some scenarios may fail: for example the file won't be automatically copied to the output folder, and when checking dependencies before a rebuild, it might not be able to understand which files to check, and what (or how) to rebuild.)
Visual Studio (at least up to 2008, not sure about 2010) also allows the use of nmake files, but then I think you're stretching the definition of "a Visual Studio project".
But under "normal" circumstances, one project implies one output. And in order to get two executables, you'd normally create two projects.
You need a solution which includes two projects. Have a read of the Visual Studio documentation on solutions and projects.
Here's my solution, since nobody in a Google search seems to suggest this method. It's quite simple and I've used/seen it used in other IDEs (like Code::Blocks).
Within your project, create a configuration for each output that you want. Then, only include one main source file in each configuration.
In VS, this means for each source file with main: right-click -> Properties -> Excluded From Build = Yes. So, once you're done, only one main source is built for each configuration. You can then specify a different output for each configuration in the Project Properties. I did this on VS 2010, but it should probably work with other versions.
I'm using this approach so that I can have several tests for one project, without cluttering the solution with more test projects than actual code projects.
I don't know if it can be done ,but the only change you have ,to do this ,is with custom build step.
EDIT: Since someone downvoted this ,i did a test making a dummy configuration.
In the custom build step I two Link-cmds (copied form original link-cmdline and modified it a bit) taking as input main1.obj resp. main2.obj and outputting App1.exe resp. App2.exe.
It's executed after Compiling and before linking.
It worked !
The downside is I cannot prevent (yet) the linking ot the orinal exe (which errors on duplicate main function).
Solution to this could be to have a lib project excluding the sources with main()from build and build them in the custum-step too.
So the answer to the question should : Yes ,it can be done!
You can't have more than one main() function in a single visual studio project. So you can't compile 2 executables, the only way is to make two different project in the same solution
You can create a solution with two project one for each output you want. Then head to Build menu and select Batch Build.. and select both projects.
If you want both exe files to be in one place you can specify a custom Post-build action:
For both project:
view the project properties page and in Build events select Post-Build events, then in the Command line field enter the command that will copy the output to the location you want, something like:
copy $(TargetPath) c:\yourlocation /Y
Then after you build the solution the output files will be copied to that location.
Another option you have is to use conditional compilation with sth like
main()
{
#ifdef VERSION1
call_main_logic();
#else
call_main2_logic();
#endif
}
and then define different configurations within the project. For each configuration you will then need to define preprocessor symbols appropriately (in: project settings -> configuration properties -> C/C++ -> preprocessor).
Please note, that it will be only one executable created at a time, but with switching configurations you'll get the one that does what you want at the moment.
... which may suit your needs or not, depending on more specific situation that you are in.
Edit: In addition, since different configurations create their separate output folders, you will have your both execs as outputs.
If I had a project structured like this...
a.cpp
b.cpp
c.cpp
...and I wanted to compile a.cpp and b.cpp with one set of compiler options, and c.cpp with another set, how would I do that?
I think the easiest way would be to separate them into different projects based on the compiler options you require, and then set up your dependencies appropriately to link them all into your final executable.
Depending on what options you need, exactly, you might be able to use the corresponding pragmas in the source code - e.g. #pragma optimize.
That said, be warned that, with some compiler options, files compiled with different ones may be binary incompatible - for example, /vmb vs /vmg.
One option is to create a new group (or 'filter' in VS.Net parlance) to make it obvious which group of files are affected by the particular settings. It can be something of a maintenance headache otherwise as it's difficult to see which files have got different settings without opening the .vcproj file in a text editor.
The simplest way (although not the easiest way to maintain) is to right click on your source file in Solution Explorer and select "Properties". From there you can customize your compiler options for the selected source file.