Monorepositorio con C++: organización de código para principiantes

¿Qué es un monorepositorio y por qué es necesario en C++?

Un monorepositorio (monorepo) es un enfoque de gestión de código donde todos los componentes del proyecto, bibliotecas, utilidades e incluso la documentación se almacenan en un solo repositorio. Para proyectos en C++, esto es especialmente relevante, ya que el lenguaje tradicionalmente requiere una estructura clara de archivos y dependencias.

Ventajas del monorepositorio para C++:

• Versión única de dependencias — todos los módulos utilizan la misma versión de las bibliotecas, lo que elimina conflictos de ABI.
• Compilación simplificada — un solo CMakeLists.txt o sistema de compilación gestiona todo el proyecto.
• Commits atómicos — los cambios en varios módulos se pueden combinar en un solo commit, lo que simplifica la revisión de código.
• Refactorización sencilla — un cambio de API en un lugar se ve inmediatamente en todos los módulos dependientes.

Sin embargo, el monorepositorio no es adecuado para todos: si los equipos son completamente independientes y utilizan diferentes versiones de compiladores, es mejor considerar un multirepositorio. Para principiantes, el monorepositorio es una excelente manera de evitar dolores de cabeza con la configuración de rutas y dependencias.

Parte principal: creando un monorepositorio para un proyecto C++

1. Estructura de directorios

Una estructura correcta es la base de cualquier monorepositorio. Plantilla recomendada para C++:

my_monorepo/├── CMakeLists.txt          # Archivo CMake raíz├── cmake/                  # Módulos CMake auxiliares│   └── helpers.cmake├── libs/                   # Bibliotecas│   ├── core/               # Núcleo del proyecto│   │   ├── CMakeLists.txt│   │   ├── include/core/│   │   └── src/│   └── utils/              # Utilidades│       ├── CMakeLists.txt│       ├── include/utils/│       └── src/├── apps/                   # Aplicaciones ejecutables│   ├── main_app/│   │   ├── CMakeLists.txt│   │   └── main.cpp│   └── test_app/│       ├── CMakeLists.txt│       └── main.cpp├── tests/                  # Pruebas (si no están integradas en los módulos)│   └── test_core.cpp├── scripts/                # Scripts de compilación y CI│   └── build.sh├── .gitignore└── README.md

Regla clave: cada módulo (biblioteca o aplicación) debe ser autosuficiente. Contiene su propio CMakeLists.txt, archivos de encabezado en include/ y código fuente en src/.

2. Configuración del CMakeLists.txt raíz

El CMakeLists.txt raíz gestiona toda la compilación. Debe definir la configuración común del compilador, el estándar de C++ e incluir los módulos hijos:

cmake_minimum_required(VERSION 3.20)project(MyMonorepo VERSION 1.0.0 LANGUAGES CXX)

# Establecemos un estándar C++17 único para todo el proyectoset(CMAKE_CXX_STANDARD 17)set(CMAKE_CXX_STANDARD_REQUIRED ON)set(CMAKE_CXX_EXTENSIONS OFF)

# Opción para compilar pruebasoption(BUILD_TESTS "Build tests" OFF)

# Incluimos módulos auxiliaresinclude(cmake/helpers.cmake)

# Agregamos subdirectorios con bibliotecasadd_subdirectory(libs/core)add_subdirectory(libs/utils)

# Agregamos aplicacionesadd_subdirectory(apps/main_app)add_subdirectory(apps/test_app)

# Si las pruebas están habilitadas, las incluimosif(BUILD_TESTS)    enable_testing()    add_subdirectory(tests)endif()

3. Ejemplo de biblioteca: libs/core

Consideremos la biblioteca core, que contiene una clase para trabajar con números. Estructura de archivos:

libs/core/├── CMakeLists.txt├── include/core/│   └── calculator.h└── src/    └── calculator.cpp

Contenido de include/core/calculator.h:

#ifndef CORE_CALCULATOR_H#define CORE_CALCULATOR_H

namespace core {

class Calculator {public:    Calculator() = default;    int add(int a, int b);    int multiply(int a, int b);};

} // namespace core

#endif // CORE_CALCULATOR_H