Project Structure question

1

I am trying to understand best practise for structuring a development project. The main purpose of the exercise is to learn how to integrate multiple (separate) library projects under one umbrella test project.

At present, my structure is:

workspace

  • testProject
    • lib
      • library1
      • library2
      • library3
    • src
      • main.cpp
  • library 1
    • lib1.h
    • lib1.cpp
  • library 2
    • lib2.h
    • lib2.cpp
  • library 3
    • lib3.h
    • lib3.cpp

Within each library (library1,…2,…3) etc. are two library files (.h/.cpp)
Each library is it’s own .git repository as I want to treat each library as it’s own standalone library project.

I’m running into problems working out how best to structure this so I can develop each library within vscode as a unique root within the workspace. I can add the library directories to the root of the workspace, but then this poses issues when compiling as the library projects are expected to have their code under /src which then breaks the structure when these are used as libraries.

I feel that there is most likely a simple way of solving this but I am struggling to work it out. I’m new to the platform so please forgive the question. I have searched FAQ but not located anything that answers this.

1 Like
2

For that particular structure - I see two possibilties - one should ‘just work’ and the other will probably work, but be a PITA…

  1. file system symbolic links - basically like a shortcut, wherein you will make so library1 also appears under lib… allowing it to be separate but still inside testProject… I just don’t know git will go with that… if… might have to use the .gitignore of testProject so it doesn’t try to track changes to the libraries (I’m assuming here that testProject is also version controlled. Not sure what OS you are on, but you can do symbolic links on all the OS flavours… on Windows, Link Shell Extension makes it easier than the native CLI tool… on linux there is the ln -s command… not sure what the procedure is on MacOS.

  2. git submodules… this is git’s native support for a repo inside a repo… the complication is that you need to keep syncing the submodules of testProject after commiting and pushing your changes to the various libraries… hence why I said it would be a PITA if you’re actively developing code… but it does work.