Scenario 1
A solution SolA contains only 1 project named PrjA.
PrjA is a Win32 console application, the compilation result is PrjA.exe.
How shall I split the source code files in PrjA into PrjA1 and PrjB, so that the management of the source code is easier, while the compilation result, PrjA1.exe, will be almost the same as PrjA.exe?
For example, I have PrjA :-
PrjA has 300 .cpp files.
PrjA.exe sizes 400KB.
I hope to split PrjA into 2 projects :-
PrjA1 has 200 .cpp files
PrjB has 100 .cpp files.
PrjA1.exe is also around 400KB.
I'm not sure how to setup PrjB or what will be its compilation result.
Assume PrjB compiles to PrjB.DLL, sized 100KB, I hope PrjA1.exe will somehow embed PrjB.dll inside itself. Thus the size would be 400KB.
I don't want a 300KB PrjA1.exe, which will dynamically link to 100KB PrjB.dll in runtime.
Question: How shall I set PrjB, and how shall I set the link between PrjA1 and PrjB?
Scenario 2
Same as Scenario 1, just this round PrjA's compilation result is a windows DLL, named PrjA.dll, how shall I split PrjA into PrjA1 and PrjB?
The development environment is Visual Studio 2013 under windows 7 64-bits, but the compilation results are 32-bit.
This is how you move existing code into static library. I use VS2015, it should be the same with VS2013, but I can't check that. I start with the following solution structure:
First thing to do is to add new project to the solution.
File -> Add -> New project -> Win32 Project
Check Static library and uncheck precompiled header
Then click Show all files icon in the solution explorer for both projects. This turn filters off and shows project folder as it is. It should look like this:
Drag and drop all needed files from one project to another:
Now reference your library. Uncheck Show all files icon to show References. Right click -> Add reference and check your static library project:
Last thing to do is to add include directory to the project that uses the library. This is done in project properties. Be sure to check All configurations and All platforms:
That's it. Now when you build your solution, VS builds your static library, builds your main project and links them together. The result should be identical as if everything is in the same project.
Related
I am trying Unit test using Gtest.
I am creating a another project that has file from the original project (By linking) that is to be tested. In the new project I then create Fake Implementation and Mocks of the additional dependencies of the function or Unit I want to test. In the file from the original project I am using #ifdef to include original dependencies or the fake implementation
The problem I am facing is I need to compile the files in particular order so that the fake implementations are included when test project is build.
I am using MCUXpresso on Windows 10 with MinGW, GNU Builder
Anticipating any workaround or way to get control over order in which files are compiled.
#ifdef IsTesting //This is part or original project, original header files
#include "Fake_dependency"
#else
#include "Original_Dependency"
#endif
Then in the new project I define
#define IsTesting true // Part of Test_Project, followed by other code for testing
when I compile the new project or test project I need this file having this variable defined to be compiled first or earlier than the file that I am linking from the Original project
Instead of defining IsTesting in your test code, you can add the definition to your Build Configuration for the test project.
Go to Properties -> C/C++ General -> Paths and Symbols -> Select the appropriate language (GNU C++) and add "IsTesting" (without any value)
If you want Eclipse to get the compiled code right (not compiled code is gray) you will have to toggle
Properties -> C/C++ General -> Indexer -> Use active build configuration as well
I am writing my own C++ project library in visual studio (couple of projects that consist of *cpp, *.h files, NOT an actual .lib file). Each of these projects is located in single Visual Studio "solution".
When I needed to use a code from one project in another, I just copied it. But that was short term solution. Now my library has grown both in size and functionality, and because of code duplication I ended up with dozens of different versions of the same file.
That single solution serve me as a playground // test ground for new ideas. I am developing projects not libs. Currently it holds about 50 projects.
I am working on visual studio 2015.
Lets say I have setup like this:
DataIO project located in */Solution/#DataInputAndOutput/DataIO/DataIO.h
consist both of DataIO.h and DataIO.cpp
Foo project located in */Solution/#Foo/Foo/Foo.h
consist both of Foo.h and Foo.cpp
DataIO.h:
#pragma once
#ifndef __DATA_IO_H__
#define __DATA_IO_H__
// ...
extern FILE * const logFile;
// Bunch of function declarations
#endif // !__DATA_IO_H__
I know that this is not a "Minimal, Complete, and Verifiable example" but my problem lies in logistic of things, not things themselves. And I believe that my description is sufficient.
Problem #1: In Foo.cpp I #include "DataIO.h" (with is possible because i added additional include directories in Foo project setup) But whenever I try to compile Foo I am given following error: unresolved external symbol for every function declaration inside DataIO.h and that one external variable. How Can I Fix this problem? Do I need to create a DataIO.lib to keep things straight?
I tried to add DataIO.h and DataIO.cpp into Foo project directly (NOT copy it, just add it into project) but that seems like a bad idea...
I recommend trying out the new "Shared Items Project" in VS2015+. A Shared Items Project is literally just a set of files. The project itself doesn't build anything. In fact, there are no (or almost no) compilation or linkage settings in a Shared Items Project -- those settings come the the project that references the Shared Items Project. When you reference a Shared Items Project from some other project FOO, the build of FOO happens as if the files of the Shared Items Project are items of the referencing project.
Short of that, you can set up your shared projects to build .libs and then use Project References within Visual Studio to automatically set up the linkage. I think you have to manually set up the include paths when doing this, though.
The best way to do this is to factor out common code into a library so the common code resides in one place. And then have your projects use the library - via an include file and linking with said library.
I'm porting a C++ application from Unix and the original developer created several files with main() functions, then use Makefile to choose which main() to use.
How do choose which file contains the main() function in Visual C++ 2010?
Currently, when I compile I get a linker error due to duplicate main() symbols.
The only thing I can think of is macro conditional.
Any other ideas?
Multiple main functions mean that the original code does not create a single executable, but rather a set of them. You should figure out what parts belong to each one of the executables (read the Makefile) and then create different projects inside the solution one for each one of the executables (do the same for the libs). Then you can use the IDE to select which executable you want to compile/run.
in the Configuration Properties for each source file (right-click in Solution Explorer) you can select 'Excluded From Build'. As this is a per-configuration setting, you can add some configurations and mutually exclude the files with main(). For instance for configuration 'MainA' you include maina.cpp and exclude mainb.cpp and mainc.cpp, for 'MainB' include mainb.cpp and exclude maina.cpp and mainc.cpp, etc.
Another option would be to have only one main() and select the appropriate source using arguments or a configuration file. Or, maybe the best solution, create one project for each main file and put the common parts in a static or shared library.
I'm building a project in C++ which uses DirectShow's video capture library to connect to a camera. The video card manufacturer (BlackMagic) has provided .idl (Interface Definition Language) files which add new capture graphs to the standard collection.
Thing is, I've never come across a .idl file, and the very vague "include the file" direction doesn't help much. Including it with a #include directive doesn't throw up any errors, but the program also fails to pull in the various definitions which I presume it's intended to add, since it's the only file I'm told to include with the project.
My question is: how should one include a .idl file in a project?
For example: you have an AFileName.idl
1. Add the AFileName.idl to you project: Right Click on The project->Add->Existing Item...
2. Click Right on The AFileName.idl from the project->Compile
3. The step 2 will generate AFileName_h.h, AFileName_i.c, AFileName_p.c,...
4. Now you can #include "AFileName_h.h" and use it, you also may need
to add AFileName_i.c or other generated files to your project
depending on your needs.
Observation: the steps are described for VS2008 but I don't think VS2010 is different in that perspective.
Is there a way to set Visual Studio solution parameters so it just create precompiled headers without building whole solution.
Specifically, it is a huge c++ solution with many projects in itself.
Thank you.
Only select the pch creator source file (usually stdafx.cpp), and compile that (Ctrl-F7, or right-click it and select 'Compile')
More info since it doesn't seem to be working for you:
In every project that uses a precompiled header, there is one source file that is used to create the pch file, and the rest only use the pch file. This source file usually only consists of one line:
#include "StdAfx.h"
"Stdafx.h" is the default precompiled header file name in Visual C++, it could be something else for you. If you compile "StdAfx.cpp" by itself, that generates a file with the name "Your_Project_Name.pch" (again, that's only the default). You should see it in the intermediate directory, the same one where all the obj files are. This is the precompiled header. If you did like I said, and selected 'Compile' and not 'Build', then no other files will be compiled, and no linking will take place.
If that still does not solve your problem, then I have no idea what you are asking.
Here's an article describing the benefits and how to set it up.
If you have larger projects, it is definitely worth the few clicks and the extra disk space.
The article says you need to add stdafx.h to all sources and headers; it's not correct. It's sufficient to add to sources - make sure it's the first line though as everything before it will be ignored.
The article does not mention it, but you'll be getting errors from sources that do not include the stdafx.h. You have a choice to resolve this error: you either add it, or exclude the source(s) from the precompilation process.
To exclude source files:
select source file(s) in the solution explorer; yes you can select more at once,
right click on the highlighted source file,
click properties from the pop-up menu,
select 'All configurations' from the combo-box on top,
under C-C++ configuration click 'Precompiled headers',
on the right-hand side select 'Not using precompiled headers',
click apply,
click ok.
Enjoy your new builds in a few seconds from here on (the first build will take longer).
If you right-click any Cpp files except stdafx.cpp from your project and set Excluded from build to Yes, it will only generate the precompiled header.
You can achieve the same result through the command line or if you create new project containing only your stdafx.cpp