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.
Related
So I have a CMake project which I open in Visual Studio 2019 with the "Open Folder" option. From here I can build and compile it without any errors (CMake is using the IAR Compiler (iccarm.exe) as specified in the toolchain file). So far so good.
The problem is that IntelliSense, despite finding all necessary header files, shows lots of errors mainly related to "undefined __INTxx_T_TYPE__".
As far as i know thouse double underscores indicate that it's a compiler internal data type, which is not defined in any header file, which would also explain why IntelliSense reports that it's not defined (even if the compiler knows the type). I guess to counter this problem, IntelliSense does support different modes like "windows-msvc-x86" or "linux-gcc-arm". But there is no option for IAR compiler.
So my question: How can I get IntelliSense running in this project ? Is there a way to add a custom IntelliSense mode for the IAR compiler ? Can i add header files only for IntelliSense in which the missing types are defined ? Is there a way to tell IntelliSense not to worry about those types / ignore the types ?
Ok just for the unlikely case someone has the same problem, here is my "solution" (sort of):
I created a header file with all the internal types used by IAR and called it "intellisenseHeader.h". You can find the internals here (https://www.gaio.co.jp/support/user/faq/winams/docs/sample_predef.pdf), but in my case i had to add some definitions by myself. The problem is now, that it won't compile anymore, because the IAR compiler, now finds 2 definitions (the internal definition and the one in the header file). So we need to fix this again:
I put the include inside a #ifdef USE_INTELLISENSE_HEADER.
I created two Visual Studio configurations. In the first one, CMake will set the preprocessor directive and the intellisenseHeader file will get included. In the other one i didn't set it.
So what's the effect of this ? If you are in the configuration, where the header is included, IntelliSense works but you can't compile. And if you are in the other one you can compile, but IntelliSense doesn't work anymore. So now i need to switch between the configurations, everytime i want to compile or write some code... Not the best solution but still better than nothing.
EDIT: Ok just realized you can use __INTELLISENSE__ as mentioned in # Richard Critten comment, and therefore don't need to use multiple configs.
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.
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.
We're looking for a way to include some sort of build ID automatically in our builds. This needs to be portable (VC++, g++ on Linux and Mac) and automatic. VC++ is what matters most, since in the other environments we use custom Python build scripts so I can do whatever I want.
We use SVN, so we were looking at using the output of svnversion to write the revision to a header and include it. This has problems : if we put the file in SVN, it will appear as modified every time, but it would be a superfluous commit and in a sense generate an infinite loop of increasing revisions. If we don't put the file in SVN and just create it as a pre-build step, the sources wouldn't be complete, as they'd need the pre-build step or Makefile to generate that file.
We could also use __DATE__ but we can't guarantee the file that uses the __DATE__ (ie writes it to a log file) will be compiled if some other file is modified - except if we "touch" it, but then we'd cause the project to be always out of date. We could touch it as the pre-build step, so it would get touched only if the rest of the project is out of date, thus not causing a spurious compile, but if VC++ computes the dependencies before the pre-build step, this wouldn't work (the file with __DATE__ won't get compiled)
Any interesting ideas?
We're using the output of svnversion, written to a header file and included. We omit the file from the repository and create it in a pre-build step; this has worked quite well for us. (I'm not sure why you object to using a pre-build step?)
We're currently using a Perl script to convert svnversion's output into a header file; I later found out that TortoiseSVN includes a subwcrev command (which has also been ported to Linux) that can do much of the same thing.
If you don't like the idea of an include file not in source control that is required for a build, consider a batch file or other build step that programmatically creates a file/include and call the svnversion within your build process.
basically GENERATE the file so you don't have an unversioned and required file.
EDIT
Josh's subwcrev is probably the best idea.
Before that was implemented I wrote my own hacky tool to do the same thing - do replacement in a template file.
It could be as simple as:
% make -DBUILD_NUMBER=`svnlook youngest /path/to/repo`
I'd look at SvnRev. You can use it as a custom pre-build step in VS, or call it from a makefile, or whatever else you need to do, and it generates a header file that you can include in your other files that will give you what you need. There's good documentation on the site.
SubWCRev is another option, though the Linux port is newer, and I don't know that a Mac version exists. It's very useful on Windows for .NET (which I'm guessing isn't an issue for you, but I'm adding this for future reference), because it allows you to create a template file that can be used to generate, for example, the Properties file for a .NET assembly.
Automatic builds can typically be full, clean builds. In that case, you start in a clean directory and there would be no issue with __DATE__ in any case. Otherwise, see Paul Beckinham's idea.
Why not tie a GUID to it, almost every language has support for generating one, or if your's doesn't there are alot of algorithms for that around.
(Although, if you do use subversion, I personally like Josh's idea better!)
I have just come across a Visual C++ option that allows you to force file(s) to be included - this came about when I was looking at some code that was missing a #include "StdAfx.h" on each .cpp file, but was actually doing so via this option.
The option can be found on the Advanced C/C++ Configuration Properties page and equates to the /FI compiler option.
This option could prove really useful but before I rush off and start using it I thought I'd ask if there are any gotchas?
I would say the opposite to litb above if you're using precompiled headers. If you use "stdafx.h" as your precompiled header and have code like this:
#include "afile.h"
#include "stdafx.h"
then you'll be spending an age trying to figure out why "afile.h" isn't being included. When using precompiled headers, all the includes and #defines are ignored up to the "stdafx.h". So, if you force include the "stdafx.h" then the above will never happen and you'll get a project that uses the precompiled option efficiently.
As for litb's comment about finding macros, good IDE's usually have an option to jump to the definition of a symbol, whether it be a #define, function, class, etc.
I would discourage from /FI (MSDN says it's called /FI . Not sure whether i looked at the right page though), simply because people or yourself reading the files don't notice a header is magically included anyway.
You can be sure this will cause much debugging time for someone that wants to figure out where specific macros come from, even though there are no #include lines at the top of the file.
Force includes is also helpful for automatically generated source files. Our system uses a tool that generates many source files but they don't include our pre-compiled header file. With "force includes" compilation of these files is now faster.
Optionally, it would be possible to write a script to insert the #include line in those files after generation and before compilation. But why go to that trouble?
I'd side with litb: don't do the forced includes. Having the code be explicit makes it easier to know what's going on for a new user. It also makes it easier to know what's going on if you ever need to port the code to a new platform.
Note that if the code uses templates, Visual Studio usually can't track down the definitions correctly. Perhaps 2010 will be better, but even VS 2008 is problematic on this front.
I wouldn't use it that often but it has its uses. I have used it to add a header that suppressed some warnings to all cpp files so that I could turn on /W4 or /Wall for the project and not have to edit all of the cpp files to include the warning suppression header first. Once eveything was working I DID go back and edit all the cpp files but for a proof of concept /FI was useful.
Likewise you can use it to force a precompiled header into cpp files in some build configurations but not in all (in case you want to have a build configuration that DOESNT use precompiled headers and that makes sure that each cpp only includes exactly what it needs to). However using #pragma hdrstop is, IMHO, a better way to achieve this.
I've talked about all of this on my blog here: http://www.lenholgate.com/blog/2004/07/fi-stlport-precompiled-headers-warning-level-4-and-pragma-hdrstop.html in a little more detail.
Save this function for when something weird comes up - like if you want to include a header in a generated source file. Even then there are likely better ways.