Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# C++/Python Project Template

This is a standardized C++/Python project template for DALSA projects that will be hosted on GitHub, designed to help project owners quickly set up new projects with a consistent structure and DevOps features. Its goal is to ensure maintainability and collaboration by enforcing standards that make future contributions and usage seamless. The template integrates **Sphinx** + **Doxygen** for unified documentation of both C++ and Python packages, and uses GitHub Actions to automate the generation of web-based documentation, code rewrites to follow a consistent style (formatting), code analysis (linting), and execution of tests.
This is a standardized C++/Python project template for DALSA projects that will be hosted on GitHub, designed to help project owners quickly set up new projects with a consistent structure and DevOps features. Its goal is to ensure maintainability and collaboration by enforcing standards that make future contributions and usage seamless. The template integrates **Sphinx** + **Doxygen** for unified documentation of both C++ and Python packages, and uses GitHub Actions to automate the generation of web-based documentation, code rewrites to follow a consistent style (formatting), and code analysis (linting).
This template introduces a certain structure so that users and contributors can quickly understand your project.

---
Expand All @@ -9,8 +9,8 @@ This template introduces a certain structure so that users and contributors can

.
├── lib/ # Library for C++ and Python packages
│ ├── cpp_pkg/ # C++ package
│ └── py_pkg/ # Python package
│ ├── cpp_pkg/ # Dummy C++ package
│ └── py_pkg/ # Dummy Python package
├── docs/ # Documentation built by Sphinx + Doxygen via Breathe
├── architecture/ # Component-based documentation
├── code/ # Code-based documentation
Expand All @@ -37,9 +37,9 @@ All documentation, on the other hand, is stored in `docs/`. Documentation is a c
- Generates **XML output** used by **Breathe**, a bridge that lets **Sphinx** include C++ documentation.

### GitHub Actions
- **Linting**: Automatic linting (ruff for Python, clang-tidy for C++)
- **Formatting**: Automatic styling (ruff format for Python, clang-format for C++)
- **Documentation**: Automatic build and deployment to GitHub Pages
- **Formatting**: Automatic styling (ruff format for Python, clang-format for C++) before merging into main
- **Linting**: Automatic linting (ruff for Python, clang-tidy for C++) before merging into main
- **Documentation**: Automatic build and deployment to GitHub Pages after merging into main

## Before Using This Template
If you haven't done so already, check the following:
Expand Down
2 changes: 1 addition & 1 deletion docs/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -162,4 +162,4 @@ In order to quickly start working with the project and provide value for users,
sphinx-build -b html docs build/html
```
5. Push changes – GitHub Actions will automatically:
- Build and deploy documentation
- Build and deploy documentation when successfully merging into main
2 changes: 1 addition & 1 deletion lib/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -150,7 +150,7 @@ This allows automatic documentation generation via **Sphinx** and **GitHub Actio

Write tests using your preferred framework. This template does not enforce any strict requirements for testing, allowing developers to focus more on writing and improving the core functionality. However, it is strongly recommended to test the most critical and foundational parts of your packages. In this way, in case of contributions, any new code added should not break existing functionality or introduce regressions. Well-tested core components act as a safety net, ensuring that changes are reliable and maintainable. They also help contributors understand the expected behavior and integration points of your package.

> **Important**: Code must be tested before merging to `main`. If new code is added, corresponding tests must be created. This ensures structured contributions and avoids regressions.
> **Important**: Code must be tested before merging into `main`. If new code is added, corresponding tests must be created. This ensures structured contributions and avoids regressions.

---

Expand Down