From 11f5073a3f1c61f0b23780c4612766290496676e Mon Sep 17 00:00:00 2001 From: Fiftytwo Date: Fri, 21 Jul 2023 23:14:09 +0200 Subject: [PATCH] Replace outdated links in README-dev.md --- README-dev.md | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/README-dev.md b/README-dev.md index cb5f1fa1..deb3d8a6 100644 --- a/README-dev.md +++ b/README-dev.md @@ -1,20 +1,25 @@ # README for developers + This file contains a ton of information useful for development of the game ## Repository setup + All the repositories related to Colobot can be found on our GitHub organization page: https://github.com/colobot ### Main code repository + This is the repository you are currently in. This repository contains all the source files of Colobot, along with some 3rd party libraries, testing framework and build files for CMake. ### Data repository + The data repository is available at: https://github.com/colobot/colobot-data This repository contains the data files necessary to run the game. These are level files, textures, models, sounds, music, help files, translations, etc. It contains many binary files, and so, it may grow up to considerable size. If that becomes a problem, we may remove some old revisions of binary files to free up space. ### Branch setup + Current setup is as follows: * branch **master** - will always contain the best-playable version of the project so that new users could download and compile the project without problems. This branch is not intended for actual development but an integration branch for more "public" releases. The changes should be pulled from general development branch - *dev*. This branch will also have tags at certain commits to denote releases. @@ -23,11 +28,13 @@ Current setup is as follows: Other **dev-*** branches may be created as needed, for work on major rewriting, or focusing on a set of features. ## 3rd party libraries + 3rd party libraries are bundled in `lib/`. They are provided for ease of use since the standard packages are rare in OS distributions. In case of GTest and GMock, CMake tries to detect if they are available in the system. If so, the system-provided versions will be used. ## CMake build system + The build system is as follows: * `CMakeLists.txt` - definition of project, list of required packages, build type setup, general compiler options and reference to src subdirectory, @@ -59,6 +66,7 @@ Note that the recommended way of building the project is to use separate build d ``` ## Tests organization + Tests are kept in `test/` directory which includes: * `test/cbot` - CBOT interpreter for test purposes, @@ -67,6 +75,7 @@ Tests are kept in `test/` directory which includes: Each test directory contains own `CMakeLists.txt` specifying targets. Note however that the only targets added as automated tests in CMake are in `test/unit` directory. The other targets are used as development support tools, not automated tests. Tests can be enabled or disabled using CMake option TESTS (OFF by default). To run the automated tests (you must be in the build directory): + ``` ./colobot_ut # or: @@ -75,25 +84,26 @@ Tests can be enabled or disabled using CMake option TESTS (OFF by default). To r ctest -V . ``` -For unit testing, we use Google Test framework (http://code.google.com/p/googletest/) and for mocking objects and function calls, GMock library (http://code.google.com/p/gmock/). +We use [Google Test](https://github.com/google/googletest) for unit testing and [Hippomocks](https://github.com/dascandy/hippomocks) for mocking objects and function calls. -Note that currently, there are very few well-tested parts of code. It is quite impossible to write unit tests for all the code we have but we should test as much code as possible, if not at unit level, then at module level. Hence the test environments and code snippets that enable us to test parts of code without actually running the full-fledged game. +Note that currently there are very few well-tested parts of code. It is quite impossible to write unit tests for all the code we have but we should test as much code as possible, if not at unit level, then at module level. Hence the test environments and code snippets that enable us to test parts of code without actually running the full-fledged game. ## CI and automated builds -Our team is not large, but since compiling the whole project is lengthy and requires some knowledge, we use some automated services to facilitate the development. -Currently we use Jenkins server hosted at http://compiled.colobot.info/ to run tests and provide compiled game binaries. +Currently we use [GitHub Actions](https://github.com/colobot/colobot/actions) to run tests and provide compiled game binaries. Testers are encouraged to use these packages to test the game and report any problems. ## Code documentation -[Doxygen](http://www.stack.nl/~dimitri/doxygen/) is used as the documentation tool. -The documentation is extracted from comment blocks in code by running `make doc`. The resulting HTML files are available in ''doc/'' inside the build directory. Generated documentation files '''will not''' be included in the repository. The idea is that anyone can generate the documentation at any time, in his local copy. Our Jenkins also builds documentation after every commit, see http://compiled.colobot.info/job/colobot/job/colobot/job/dev/Doxygen/ +[Doxygen](https://www.doxygen.nl/index.html) is used as the documentation tool. + +The documentation is extracted from comment blocks in code by running `make doc`. The resulting HTML files are available in ''doc/'' inside the build directory. Generated documentation files '''will not''' be included in the repository. The idea is that anyone can generate the documentation at any time, in his local copy. GitHub Actions also builds documentation after every commit, see https://github.com/colobot/colobot/actions Diagram generation (class inheritance, include dependencies, etc.) is disabled for now to speed up the generation process but you can of course enable it in your local copy. Currently, only a few classes and structs are documented properly. If you can, please expand the documentation wherever possible. ## Coding rules + Please refer to the [CONTRIBUTING.md](CONTRIBUTING.md#coding-style) file.