Consider visual studio solution with multiple projects, some source files are used in several projects.
I'm currently including source files used in multiple projects in each project, but that leads to same source file being compiled for each project. Is there any way to specify single project to be a one that builds files, and link against built objects in all the other projects.
I'm aware of option to create a static lib, but I would like to know if it is possible to specify dependencies directly between the projects in solution - like you can do by writing makefile.
Search has revealed single question on the subject from 2010, but there is no suitable solution there:
How to use the same obj files in different projects in the same solution
You can specify project dependencies (http://msdn.microsoft.com/en-us/library/et61xzb3(v=vs.80).aspx) but in order to use the same source between the projects you'll need to create a static lib or a dll and link with that. You can set up these configurations in the project settings as well so you won't have code that shows the linking, it's all done in compile/linking statements
One thing you might consider is to create a solution where you have multiple projects, and you properly set the building dependency of each your projects such that the 'base project' will always built before other projects depending it it are built.
as you mention Static lib is the best project type to do that. group all your common file in a static lib project, and on your DLL or exe project create a dependency to the lib by using the "add dependency" option you should get with a right click on your project in the VS solution explorer pane.
take care about 1 thing : if you create a cascade of dependency between Libs they will become bigger and bigger (the last lib of the chain will contain all the symbol of all the other ... a kind of cat of the .obj file....)
Related
I have multiple C++/C# Visual Studio Solutions some depend on each other, in the building Process I make the building order manually and build them one by one until the end.
now I will be going to continuous Integration "CI",
My Question Is: is there any tool or method to automatically generate the correct building order?
My Project Structure Looks Like that:
All_Code:
VS Solution A:
Project A.1
Project A.2
VS Solution B:
Project B.1
Project B.2
Let's say Project B.1 Depends on A.1 and A.2 Depends on B.2
so, when I am building I order them as follows:
A.1
B.1
B.2
A.2
Create one solution (.sln) file that contains all the projects in the CI build and plan to use that solution file for the CI build.
Now, you can either discard the use of the existing 'A.sln' and 'B.sln' solutions and add project references in the projects (Project B.1 would have a project reference to A.1 for example) or set the build order in the new .sln file itself.
Prefer to use project references if possible because they have options and capabilities that the other approach doesn't offer. But note that a project reference is a change to the project file. Further the referencing project and the referenced project must both be in the solution. That means that using project references will break the existing 'A.sln' and 'B.sln' solutions.
You can, however, create solution filter files (.slnf) for the new .sln to create 'views' that are equivalent to the 'A.sln' and 'B.sln'. (See Filtered solutions in Visual Studio.)
If you need to keep 'A.sln' and 'B.sln' and keep them useable, you can manually set the build order in the new solution. In the solution properties in the 'Project Dependencies' section, manually set each project's dependencies. This is stored in the .sln file. The project files are not changed. However, the dependencies set in the .sln file will need to be kept in sync with the project's actual dependencies.
The tooling will automatically determine the build order based on both the project references in the projects and the project dependencies in the solution.
I have a Remote Solution for my Raspberry Pi (A remote Linux system) in Visual Studio Community 2017 which consists of two C++ projects.
As Project_B is dependent on Project_A. I added the suiting project dependency under Solution->Properties->Common Properties->Project Dependencies.
All the includes from Project A in Project B declared as following:
#include "../Project_A/header.h"
(They should be correct as it compiles)
When I build Project_B Project_A compiles and is linked (according to the output view) and Project_B is compiled but the linker crashes as it cannot find the definitions of the functions from Project_A.
Sometimes, the whole IDE crashes and needs a restart.
Compiling and linking only Project_A works fine.
As a workaround I have copied all files from Project_A to Project_B and modified the includes accordingly and removed the project dependency.
Like that, it works.
However I would like to have an working, clean solution for linking two project on a remote linux system in Visual Studio.
Thanks in advance.
4-Apr
Thinking about this, I wonder whether I need to take a step back.
A Visual Studio project takes a bunch of source files and creates one (we'll leave it simple for now) target, e.g. an executable. It also creates several intermediates along the way, most importantly the object files.
So how do you use the funtionality of one project in another? The simplest way is source include which works just like you've done with the headers, add the sources from projectB to projectA. Not the most efficient solution and it can get messy but it will work.
The most common approach is to build projectB into a library. Then projectA, which creates the executable, links to the projectB library.
To create projectB's library, set the project type to static library and have projectA link to it; this is what my original answer addressed.
===============
Solution->Properties->Common Properties->Project Dependencies allows you to specify the build order, i.e. projectA depends on projectB so projectB should be built first. It does not create cross-project references for compiler and linker.
You must tell projectA where to find the headers and binaries of projectB on the Pi. In the case of headers you can, as you have done, use relative paths but it would be more general to specify the location of projectB files in Additional Include Directories under C/C++ - General in the VS project properties.
For libraries, you must specify Library Dependencies under Linker - Input in the project properties and Additional Library Directories under Linker - General. Alternatively, for projects in the same solution, you can add a Reference to projectB under projectA.
I'm currently developing a C++ Solution in Visual Studio. My Solution relies on different thirdparty libraries and several projects of my own. Most of those projects rely on the same thirdparties, and thus, I created a Makefile project for each of these thirdparties libraries to save me some time with the linkage, since now I would only need to reference the thirdparty Makefile project.
One of those thirdparties outputs several .lib files, which on my Makefile project would like to config. So I went to project properties -> NMake -> Output. The thing is, it only seems to allow one output. Is it possible to put several .lib outputs? Am I doing the correct approach?
Thanks!
I've searched far and wide and havent' found a solution for this. I think the only approach is to create a project for each .lib file. It's a bit of overwork, and it's easy for a solution with several external dependencies to grow large on projects.
I am quite used to Linux development and Makefiles, and started using (Windows and) Visual Studio not so long ago.
What I want to do is (I think) quite simple, but I can't seem to find how to do it using Visual Studio.
I have to write an application, which I can divide into several independent sub-parts. I want to work incrementally, and create several projects that together with a main file will end up with my full project.
What I basically want is to be able to write a small project, have a main for it so that I can fully test it, and use it as a dependency for the next project. In this case, the smaller main would be deactivated (or I can comment it), and I would just change the startup project.
If I find a bug in a subset while writing my bigger software, I could just change the startup project and solve it at a smaller scale.
Well, that's what I do all day long in Python and Java.
I tried to create new projects into my project, but I always end up having linking problems, where my main projects knows about the files in the sub projects, but not the smaller ones, etc. . .
So, is there a guide somewhere I can find to work this way ?
Thank you
For individual projects:
Every individual project property sheet has a C++ options page. Here you can specify the 'Addional Include Directories' in a comma separated form.
Similarly, there should be a property sheet for Linker where you can specify the 'Addional Include Dependencies' and the names of the libraries it depends on.
For linker dependencies of the main executable:
Go to that main project, go to its properties, go to common properties and select 'Framework and References'. This should give you a list of all the projecs that are in your solution. Keep adding them and Visual Studio should add the right linker flags automatically for you.
Sorry, have no access to the computer now else would have provided exact steps. Visual Studio can get tricky sometimes but once you use it, you'll be amazed by what it can do for you. Personally, I love it.
Hope this helps.
Thanks to Vaibhav, I was able to find a solution:
I had to :
change subproject type to lib instead of exe
Add the subprojects as project dependencies in the main project (this just sets the build order)
Comment out the main of my subprojects, to keep only one active.
Add each subproject include directory in the include repos of the main project, so that the compiler can find the header files
Add the general directory as a dependency for the linker (in this case, it is not the debug/release folder of the subprojects, but the output directory of the complete project).
Add the names of the lib files of the subprojects in additional dependencies of the linker of the main project.
To make it simple, the project dependencies capability of VS2010 just changes the order in which the projects are built. . . I miss Eclipse.
If I find a bug and want to test on of the subprojects, I have to :
change the startup project to be the subproject I want to change.
uncomment the corresponding main
change the project type to be exe instead of lib to be able to compile it.
Debug, and do everything back again to continue working on my main project.
Quite boring, don't you think ?
Looks like you trying to do manual unit testing. Use something like Google.Test. You need to make test project for every lib.
We have directory with static libs projects. Another directory with tests projects. Every test solution contains one exe project and few existing lib projects. Every project have configured dependencies. You dont need to set additional dependencies of the linker manually (paths are evil, out dir for the lib file will be taken from project settings), open project properties with right mouse button, Common properties, Add new reference and select lib project. You only need to set additional include dirs.
When you find new bug - just open test project for the library with bug, add code which cause the bug, fix it, and be happy (and sometimes run all test). And even better - use TDD.
say I have a sln which contains 10 projects(named proj1 to proj10), and proj1 is the default project which generate the EXE file.
My problem is: how to place the 'include' folder?
I mean if proj2 uses proj3(that is including its header file and linking its lib file), how to place the 'include' folder?
there are two approaches:
place all header files and lib files in a different root folder which is in the same level of the project
make every project self-close, and the other projects who want to use this project should take care of the include-path and link-path. Of cause we should give a rule to the layout of every project(e.x. every project MUST have a 'include' folder and 'lib' folder in the root folder)
any suggestion?
thanks
When it comes to Visual Studio, I don't like either of the two approaches you suggested, although mine is most closely related to your Option #2. The way I like to organise it is like this:
<SolutionRoot>
<Project1>
project1.vcxproj
someheader.h
somesource.cpp
<Project2>
<Project3>
<Project4>
<Project5>
application.sln
In case that's not obvious, that's a quasi-directory listing showing some project folders and the base solution file.
All new projects are just added to the solution using Visual Studio's default settings. Trying to go against this and making projects work like Linux projects (lib, include, src etc) just ends up causing you grief, so don't do it.
Now, I set my "additional includes" path on every project to $(SolutionDir). Then if I want to include something from Project1:
#include "Project1/someheader.h"
The advantage of this is you don't clutter up your 'additional includes', so it's easy to see at a glance what external includes a project has.
As for linking to lib files, why not take advantage of Visual Studio's project references feature. Honestly, your life will be easier. Simply hook it up so that Project2 references Project1, etc... Then you don't have to worry about libraries and linker paths. You only do that for toolkits that are outside your solution tree (eg distributions such as libpng or openssl).
Again, you free up that setting so it only shows linkages outside of the solution. The other advantage is that your build order is implicitly defined if you use references.
I would go with the 1st solution. it make the project settings simple. As the C++ projects we worked on, we always put the header files together.