I have two projects which I want to keep in separate repositories.
Project A is a large project, and project B is a small tool that was at first part of project A.
So the thing is project A needs some of the functions of project B, and project B needs the data structures defined in project A (and probably some functions as well).
I'm coming from a Go background where each module or package would have its own repo. For example, if both project A and project B had to read a particular file type, I would have a "file-reader" package in a separate repo. Is this the way to go with C++ as well?
You should separate your projects into shared libraries, and put the artifacts on Conan. Any executable would need the shared libraries from both project A, and Project B. You can also add the circular dependency to Conan, so both project A and Project B will build (i.e.. Project A depends on B to build, and B depends on A).
https://docs.conan.io/en/latest/
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.
Assume, I have project C++ project called A which uses libraries generated in project B. That two project are placed on my Gitlab instance. What I want to do, is to make Continuous Integration Pipeline for project A. That pipeline gets the source of project B, build a library and links it to project A. How to make project B accessible from project A? Many other projects, like C, D, etc. use projects' B library.
I googled this a lot and I found very poor solutions on how packages are managed in C++.
Let's suppose that I am working on a project called Project C which is dependent on C++ project Project B, and Project B is dependent on another C++ project Project A.
Currently, we use Visual Studio to develop our projects. When Project A changes, every single developer pulls the changes and recompiles the project locally. Every single developer has a lib folder with all of these dependencies that contains the DLLs and header files that we copy for each project manually.
Then since we know the dependencies, we then go to every project that is dependent on Project A, copy the dlls of Project A from lib folder and recompile those as well until we get what we want.
I know however, that C# has nuget and one can manage external dependencies and Java has maven where one can do the same.
What we currently do is a manual, error prone and extremely time consuming process. Is there a way to handle dependencies for C++? We should be able to build with the debug ddls of the dependencies when compiling as debug and the release dlls when compiling as release. For now we just need to have the latest dlls.
We have jenkins installed and if we could use that to help us that would be perfect. For java projects our java engineers compile the project and maven packages are pushed into a maven repository from where everybody else is just pooling. As simple as that. But how we can achieve similar functionality in C++?
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....)
I'm trying to set up eclipse cdt (Indigo) for a large development project and need some help on organizing the eclipse workspace. The project is in its startup phase, parts are completed, but much more is to be developed. The project covers several products each consisting of several processes and a common set of libraries. The structure is about as follows:
top/
Library/
Math/
Sys/
Com/
Include/
Math/
Sys/
Com/
Product/
Prod1/
Prod2/
I created a top workspace and want to use this for the whole project. I'm currently strugling with the Library and Include part. I need to create a new library called Err and a corresponding Err directory under the Include branch which is outside of the scope of the project created under the Library folder. Should I create this as a separate Err project in Eclipse? I tried this and the folder under Library was fine, but how then do I create the corresponding folder and files under the Include branch?
Is this the best way to organize the project or should I use one common project for all the libraries or divide the whole thing into several workspaces?