I have a big CMake solution which contain 5 projects. On this 1 project creates Main executable and rest of the 4(3 static + 1 dynamic) projects creates libraries which are linked to the main project.
MainSolution:
|-MainExecutablePrj
|-StaticLib_1Prj
|-StaticLib_2Prj
|-StaticLib_3Prj
|-DynamicLib_1Prj
The entire project is to be build for both windows and linux platforms. Now I need to create an Sub directory under MainSolution and create some testcase projects which uses the DynamicLib_1 (.lib/.so). So far what I have done is I will have different solution for each test cases and copy the required .h files and .lib(.so) files and build the test case solutions.
Its very hard for me to maintain the source code and whenever there is an change on the dynamic library I need to copy all the necessary files and rebuild the test cases again.
So I wanted to include the Test cases solutions inside my main project, so that whenever I change dynamic library project it builds the test case projects as well.
I very well know to add those test case solutions as projects under the MainSolution but I wanted to create sub-directory and put all the test case projects under that folder.
MainSolution:
|-TestCasesFolder
|-TestCase_1Prj
|-TestCase_2Prj
|-...
|-MainExecutablePrj
|-StaticLib_1Prj
|-StaticLib_2Prj
|-StaticLib_3Prj
|-DynamicLib_1Prj
Can someone help me on this
It should not be necessary to copy any files.
Let CMake find the built libraries with find_library and add a hint to the path of subdirectories build folder
Let CMake include the header files from your subproject with include_directories. Add a prefix to make it platform independent.
Regarding the tests:
All unit tests for a subproject should be places within the structure of this project and not in the root project. Place all integration tests in the root project or a separate test project as part of the root project.
Example Structure
Related
I have a main project and which there I implement some classes and functionality and also a main.cpp to run everything.
Now I try to add another project to test my main project, so I create another project in the same solution which will be my Unit Test Catch 2 for my original project.
Now I try to reference my original project inside my test project - didn't work. I also try to add in linker input dependencies my whole original folders, the debug folder and the cpp folder - didn't work.
Finally I understand that I try to search for lib file of the Original project to refer inside my Test project but cannot find lib file.
Is there another way to link between the two projects so I can call classes and functions inside my Test project and test them?
You can only link to another project if that project is build as a library. Your project is currently build as an application, so you cannot do this, unless you reorganize your project into a library and an application.
If you do not want to this, you can also add the sources files you want to test to your test project. Do not copy the files but reference the existing files in the unit test project.
Right click on "Header files" or "Source files" of your test project in the Solution Explorer, then "Add", "Existing item...". Now these sources files will also by compiled and linked when building your test project.
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.
cmake is even easier than would I could ever hope for. At the moment what I ask myself is, how can I create one (or multiple) CMakeLists.txt file(s) such that the following project structure works:
my workspace
src
project1
project2
build
project1
project2
More concretely, I have the following two constraints that should determine both my project structure and my CMakeLists.txt file:
1) I use git and would like to commit only CMakeLists.txt and my source files, build should only by generated for each particular user who would like to work on this project via an IDE of his desire
2) If someone clones my repository, he will be able to run cmake that builds the directories as described above (/my workspace/build/project1 and /my workspace/build/project2) for the IDE that he/she desires, such that he can work on this project
3) The src directories should be clean such that anyone who works on the project can do this with his/her desired IDE, change src files and maybe CMakeLists.txt and afterwards commits what he/she has done, so that everyone else can checkout again and work with it in the same way
Huge advantage for collaboration in that way! However, cmake seems to build everything just into the directory where cmake is called from.
Now, for the questions:
a) In order to create my desired directories with the corresponding builds, is there any other way than to call cmake from newly build /my workspace/build/project1 and /my workspace/build/project2 folders?
b) Do you prefer a different directory structure to collaborate?
c) If yes to b), where do you put your CMakeLists.txt file(s), from where do you call cmake from and what is the general process for building?
d) QT creates moc files which seems to work fine. Do you commit them in any way or are they just put into the build directories for everyone who checks out and you make sure that they can be used?
Build directories aren't your thing to decide. Other developers will choose where to put the build directories (I have an 'outside' setup with eclipse: https://stackoverflow.com/a/38140914/4742108). Build directories are not commited into the repository.
CMakeLists.txt is per-project. You have two projects, so they shouldn't be related in any way from the point of view of CMake. Also, you should decide whether it's necessary to commit them to the same repository.
The moc files are not commited anywhere. They are local for each build, just like *.o files or any intermediate stuff that compiler generates.
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.
I would like to use some standard layout for my linux c++ project which is built using cmake and contains some executables and a library that these execs might link to. Currently I just had a folder for the project and a sub folder for each sub project. With a CMakeLists in the top level and one in each sub level that the opt level adds.
Project-
executable1
executable2
library
However I think it would be better setup like the following
Project -
lib //Library output folder
bin //Executable output folder
src //Al cpp source files
include //All header files
test //All tests
I would have just one CMakeLists in top level.
I can easily set this up in cmake. does anyone have reasons for choosing a different layout?
I wouldn't put the lib, bin and test output directly on the project directory: if you want to make a debug and a release build, you get stuck, because you have only one placeholder. Out of source build is your friend! I would use something like:
Project
src
include
CMakeLists.txt
These will be generated when using cmake:
Project_build_dbg
bin
lib
test
Project_build_release
bin
lib
test
The layout you are proposing to use is pretty much how most of the projects are organised. And its a very well organised way of having a project. I usually also have a docs folder wherein goes all the documentation about the project. So heres my usual project setup.
Project -
lib //Library output folder
bin //Executable output folder
src //All cpp source files
include //All header files
test //All tests
docs //All project documentation ------> new addition