Development environment#

Last Updated on 2024-01-29

In the past, software development comes with a lot of pain. It takes many steps beginning from Coding, Compiling, Testing, Debugging, Build, and Deployment. All these different phases would need many commands, scripts and different packages to be installed and was difficult to maintain by a Developer.

Luckily, most of these activities are now integrated or combined into single environments known as IDE (Integrated Development Environment), which made modern software development more productive and more fun. A typical IDE today provides several essential features such as syntax highlighting, auto-code completion, search and replace, refactoring, compiler integration, debugging, version control, build and deployment etc.

Developers tend to be quite opinionated when it comes to selecting the IDE, the source code editor, automation tools, etc. Therefore, it is not the intent here to force a certain toolkit but rather to provide a coherent project structure and build system that can work in any environment while staying simple and easily maintainable. If you are starting as a C++ developer then the recommendations provided here will get you started faster. If you are an experienced developer, it is always important to understand the rationale behind some of the choices made in the asap project so that you can own the design and adapt it to your specific needs.

Requirements overview#

  • This is a starter project and as such, starting a new project based on asap should be a straightforward and simple task. The process should be automated when possible, customization should be clearly indicated when relevant and by default the starting project should work out of the box.

  • Onboarding of new developers on the project should be easy. When it makes sense, conventions and best practices should be implemented in the tooling, not the docs.

  • The overall goal is to create an environment for developing software primarily in C++ but it is often the case that scripts, tools and even system modules may be developed in other languages.

  • Development may target multiple Operating Systems and developers may use different desktop environments. At a minimum, it should be possible to develop for/on Windows 10+, Linux, and Mac OS X.

  • The build system should provide support for implementing and automating most of the steps of the development lifecycle including system build, documentation generation, deployment package creation, software quality checks (linting, static analysis, testing, metrics).

  • The tools used and automation scripts may be invoked in an interactive terminal session or in a completely hands-free CI (Continuous Integration) environment.

Choices made and rationale#

Note

These are the fundamental choices made in ` asap` that significantly influence its design and impact the extent to which it achieves the goals. There are many other small choices made which will be encountered in the build scripts, coding standards, style, etc… which are documented in the relevant places. None of these choices is cast in stone and they all can be changed or simply eliminated.

Choices were made in the design of the asap starter project, some of them are hard choices, and some are more flexible. Nothing is cast in stone in software development but some decisions will require more effort than others to change. The table below summarizes such decisions:

Decision

Rationale

Version control: git

It’s just the most widely used VCS and the one that works with github, gitlab, etc.

Variability: Not recommended.

You can use a different one if you want, but you will need to adapt the versioning and release management tooling and slightly modify the build scripts.

Build system: CMake

We need a system that works across platforms and IDEs and that can allow us to easily reuse existing OpenSource software projects. The C++ ecosystem is seriously lacking the diversity we can find for other languages, but CMake emerges as the community choice for now. The 2021 C++ ecosystem survey puts CMake at the top with 55% market share.

Variability: None.

Compilers: Clang, GCC, MSVC

All three most used compilers are tested and work well with asap. Clang is also used for linting and static code analysis and as such occupies a more strategic place among compilers.

Variability: Possible.

As long as the compiler kit is supported by CMake it is pretty straightforward to add support for it. Some changes may be required in the CMake scripts to customize compiler options, flags, etc…

Documentation: Doxygen

Doxygen is the de-facto standard for C++ API documentation and is fully supported/integrated in the build system. It can generate documentation in multiple formats, and most importantly as XML which is used to generate the integrated project documentation with sphinx.

Variability: Possible.

The use of doxygen is completely optional, and can be configured on a per-module basis. Full customization of the documentation generated is possible via the project-wide configuration file. A HTML theme is provided via Doxygen Awesome which can be easily customized or replaced if needed.

Documentation: sphinx

Project documentation may extend beyond APIs to include architecture, design, guides, etc. The OpenSource ecosystem has multiple alternatives for writing such documentation including markdown, restructuredText, html, ascii, and many variations of them.

asap recommends and has full support for restructuredText via sphinx. reStructuredText is an easy-to-read, what-you-see-is-what-you-get plaintext markup syntax and parser system. It is useful for in-line program documentation (such as Python docstrings), for quickly creating simple web pages, and for standalone documents. reStructuredText is the default plaintext markup language used by Sphinx.

Sphinx can generate documentation in many formats including HTML and has many useful extensions to augment its functionality. Among such extensions, Breathe can be used to integrate API documentation generated by doxygen.

Variability: Possible.

The use of sphinx totally optional and is opt-in on a per module basis. It is also possible to use sphinx as the master documentation system while writing mixed documents using markdown and other formats by adding extensions to sphinx.

Preferred IDE: vscode

It’s free, OpenSource, extensible, fully functional, portable, and list goes on… There really is no reason not to use Visual Studio Code. Therefore, full integration with and support for vscode is built into asap.

Variability: Possible.

Nothing in asap is tied to a specific IDE. With CMake as the build system, it is easy to open the project in Visual Studio, CLion, XCode, CodeBlocks, or any other IDE.

It is also totally acceptable to just use a terminal, and your favorite editor such as vi, Atom, Sublime, etc. Everything that can be done in the IDE can also be done via command line.