Deliverable 3.0

In this phase of the project you have to implement the design of another team. Implementation should be done in C++, using CMake as a build system. You can use any text editors or IDEs you like, as long as the project can be built with CMake, if you do not have a preference, we recommend either CLion (a full-featured IDE), or VS Code (a somewhat simpler text editor).

Your implementation must be done in a GitLab repository, see below for more details about the workflow.

In general you are free to use any tool you find useful for your workflow and feel confident using. We strongly recommend using Doxygen for automatically generated documentation. It makes it easier for everyone to navigate your project on a high-level through a generated web page with documentation. We also recommend that you use GTest for writing unit tests.

GitLab workflow

You have been using GitLab for the previous phases, and you should continue doing it for the implementation. Since every team seems to have a more or less unique workflow, we only make two hard requirements:

  • Your implementation must be in a repo that TAs can access.
  • Your implementation must have a CMakeLists.txt in the root directory that can be used to build the project with CMake.

There are also a few points where you can choose what works best:

  • You can either use the implementation skeleton provided in the template repository, or create your own repo structure. All of the content in the template repository is for your convenience only, you are not obliged to use it.

  • You can keep the implementation code in either of these places:

    • The repository with the other team's design (Recommended). You should have developer access to it from before, and this way the code lives in the same place as the corresponding design document.
    • The repository with your own design. This makes it a bit confusing, but if you already started working with this approach, it is fine to continue.
    • A new, fresh repository. This can be useful, for example, if you want to use the template repository as a base, and the repository you would otherwise work in was not using it; or the other way around, if you don't want to use the template repository code, but the existing repository is using it.

Wherever you choose to keep your code, after you are done, you must create a GitLab release with the final commit, and create a GitLab issue in the repository with the design you were implementing. The issue should be named "Implementation complete", and its description should contain a link to the release you created, whichever repository this release is in.

Resources for tools

Here we provide some links that you might find helpful to get to know the tools you are using better.

Git and GitLab

The GitLab docs have useful tips and guides about both Git and GitLab. In particular, you may want to read up on branches and merging, since it is likely that you will have to merge your work from separate branches.

CMake

CMake can be a bit daunting at first, but if you walk through the tutorial you should be able to write simple CMake files that should be sufficient for this project. You can also check out the CMake configuration provided in the template repository to get a general idea of which CMake commands you may need.

Make

Make is a more basic build system that CMake uses under the hood. You most likely will not have to interact with Makefiles yourself.

Google Test (GTest)

Google Test includes a nice introduction guide in their official repository.

Documentation (Doxygen)

Doxygen manual is somewhat verbose, but the sections "Getting started" and "Documenting the code" should contain most of the basic information.

Operating System

All of the listed tools should work on any platform, but it is much easier for TAs to provide support if you are using Linux.