DEPENDENCY_PHILOSOPHY.md
╔══════════════════════════════════════════════════════════════════════════════╗ ║ ║ ║ 📦 DEPENDENCIES: LA ECONOMÍA DEL CÓDIGO REUTILIZABLE ║ ║ La Arquitectura de las Dependencias ║ ║ ║ ║ "El 80% del código que ejecutas lo escribió otro" ║ ║ ║ ╚══════════════════════════════════════════════════════════════════════════════╝
═══════════════════════════════════════════════════════════════════════════════ 🧠 CAPÍTULO 1: LA ONTOLOGÍA DE LAS DEPENDENCIAS ═══════════════════════════════════════════════════════════════════════════════
🔷 QUÉ ES UNA DEPENDENCIA ────────────────────────────────────────────────────────────────────────────
DEFINICIÓN FUNDAMENTAL: ┌─────────────────────────────────────────────────────────────────────────┐ │ │ │ Una DEPENDENCIA es código externo que tu proyecto NECESITA │ │ para funcionar, pero que NO mantienes tú. │ │ │ │ No es tu código. │ │ No es código que escribiste. │ │ Es código que USAS. │ │ │ │ Dependencia = Reutilización + Coupling + Liability │ │ │ └─────────────────────────────────────────────────────────────────────────┘
PARADOJA DE LAS DEPENDENCIES: ────────────────────────────────────────────────────────────────────────────
┌──────────────┐
│ DEPENDENCY │
└──────┬───────┘
│
┌──────────────┴──────────────┐
│ │
▼ ▼
┌───────────────┐ ┌───────────────┐
│ BENEFITS │ │ COSTS │
└───────────────┘ └───────────────┘
│ │
┌───────────┼───────────┐ ┌───────────┼───────────┐
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
Don't Tested Community You Breaking Code reinvent code support don't changes bloat wheel Expert control API Size impl. version changes
🎭 TAXONOMÍA EXISTENCIAL: NIVELES DE ABSTRACCIÓN ────────────────────────────────────────────────────────────────────────────
┌────────────────────────┐
│ DEPENDENCY TYPES │
└───────────┬────────────┘
│
┌───────────────────────┼───────────────────────┐
│ │ │
▼ ▼ ▼
💎 CÓDIGO 🔩 BINARIO 🎨 FRAMEWORK PURO COMPILADO COMPLETO │ │ │ │ │ │ ▼ ▼ ▼
💎 NIVEL 1: CÓDIGO PURO ────────────────────────────────────────────────────────────────────────────
CONCEPTO: Source code que se integra directamente en tu build
FORMAS:
📄 Header-only libraries
┌─────────────────────────────────────┐
│ #include <magic_library.hpp> │
│ │
│ // Todo el código está en header │
│ // No linking necesario │
└─────────────────────────────────────┘
Características:
├─ Un archivo .hpp (o varios)
├─ Toda implementación inline o template
├─ No binary compilation
└─ Ejemplo: fmt, nlohmann/json, Eigen
Ventajas:
✅ Fácil integración (solo copiar archivo)
✅ No linking issues
✅ Compiler puede optimizar todo
✅ No ABI problems
Desventajas:
❌ Compilation time (re-compila siempre)
❌ Code bloat si muchos TUs incluyen
❌ No binary caching
📂 Source files distribuidos
┌─────────────────────────────────────┐
│ library/ │
│ ├─ include/ │
│ │ └─ public_api.hpp │
│ └─ src/ │
│ └─ implementation.cpp │
└─────────────────────────────────────┘
Características:
├─ Headers + source separados
├─ Debes compilar con tu proyecto
├─ add_subdirectory() en CMake
└─ Ejemplo: algunas libraries pequeñas
Ventajas:
✅ Control sobre compilation flags
✅ Debug fácil (tienes source)
✅ No ABI mismatch
Desventajas:
❌ Build time increases
❌ Tu build system debe manejar
🔩 NIVEL 2: BIBLIOTECA COMPILADA ────────────────────────────────────────────────────────────────────────────
CONCEPTO: Código pre-compilado que linkeas contra tu ejecutable
FORMAS:
📚 Static Library (.a, .lib)
┌─────────────────────────────────────┐
│ libfftw3.a │
│ ├─ Object files empaquetados │
│ └─ Linkea en tu executable │
│ │
│ Tu código + libfftw3.a → ejecutable │
└─────────────────────────────────────┘
Características:
├─ Archive de .o files
├─ Linked at compile-time
├─ Code copiado a tu ejecutable
└─ Self-contained binary
Ventajas:
✅ No runtime dependencies
✅ Portable (todo en un ejecutable)
✅ No versioning issues en runtime
Desventajas:
❌ Binary size grande
❌ Multiple copies si usas en varios ejecutables
❌ Must match toolchain (MSVC vs GCC)
📦 Shared Library (.so, .dll, .dylib)
┌─────────────────────────────────────┐
│ libfftw3.so │
│ ├─ Separate binary file │
│ └─ Loaded at runtime │
│ │
│ Tu ejecutable → references libfftw3 │
│ OS loader encuentra .so │
└─────────────────────────────────────┘
Características:
├─ Separate file en disk
├─ Loaded dinámicamente
├─ Shared entre programas
└─ Platform-specific
Ventajas:
✅ Smaller executable
✅ Shared code (una copy en memoria)
✅ Can update library sin recompile app
Desventajas:
❌ Runtime dependency (must ship .dll)
❌ Version conflicts ("DLL hell")
❌ Slower loading
📋 Interface + Implementation
┌─────────────────────────────────────┐
│ Package distribution: │
│ ├─ include/ │
│ │ └─ fftw3.h (API) │
│ └─ lib/ │
│ ├─ libfftw3.a (static) │
│ └─ libfftw3.so (shared) │
└─────────────────────────────────────┘
Flujo:
1. #include <fftw3.h> (compile-time)
2. Link contra libfftw3.a (link-time)
3. Resultado: funciones available
🎨 NIVEL 3: FRAMEWORK COMPLETO ────────────────────────────────────────────────────────────────────────────
CONCEPTO: Ecosistema completo con runtime, tools, conventions
EJEMPLO: JUCE Framework ────────────────────────────────────────────────────────────────────────────
🎯 JUCE
┌─────────────────────────────────────────────────────────┐
│ │
│ 📦 Components: │
│ ├─ Modules (audio, gui, data structures) │
│ ├─ Tools (Projucer, build utils) │
│ ├─ Resources (fonts, graphics) │
│ ├─ Examples (demo projects) │
│ └─ Documentation │
│ │
│ 🔧 Build System Integration: │
│ ├─ Own CMake setup │
│ ├─ Module declarations │
│ └─ Compiler flags management │
│ │
│ 🎨 Architecture: │
│ ├─ Message loop │
│ ├─ Component hierarchy │
│ ├─ Audio callback │
│ └─ Platform abstraction │
│ │
└─────────────────────────────────────────────────────────┘
Características:
├─ No es "una library"
├─ Es una MANERA de hacer things
├─ Opinionated architecture
└─ Bundled tooling
Ventajas:
✅ Todo incluido (batteries included)
✅ Consistent patterns
✅ Cross-platform abstractions
✅ Community & examples
Desventajas:
❌ Heavy (large download/build)
❌ Lock-in (hard to switch)
❌ Learning curve
❌ "The JUCE way" vs your way
🌐 NIVEL 4: SERVICIO EXTERNO ────────────────────────────────────────────────────────────────────────────
CONCEPTO: No código local, solo API calls a service externo
EJEMPLO: License Server ────────────────────────────────────────────────────────────────────────────
☁️ REMOTE SERVICE
┌─────────────────────────────────────┐
│ License Validation API │
│ │
│ Tu plugin │
│ │ │
│ └─→ HTTPS request │
│ │ │
│ ├─ POST license key │
│ └─ GET validation response │
│ │ │
│ ┌────▼────┐ │
│ │ Server │ │
│ │ válida │ │
│ │ license │ │
│ └────┬────┘ │
│ │ │
│ └─→ Response │
│ {valid: true} │
└─────────────────────────────────────┘
Características:
├─ No local code (solo HTTP client)
├─ Runtime dependency on service
├─ Network required
└─ API versioning
Ventajas:
✅ Zero bloat en tu binary
✅ Server-side updates sin redeploy
✅ Centralized logic
Desventajas:
❌ Network dependency
❌ Latency
❌ Service downtime = tu app fails
❌ Privacy concerns
🔌 NIVEL 5: SISTEMA / PLATFORM ────────────────────────────────────────────────────────────────────────────
CONCEPTO: Libraries provistas por el Operating System
EJEMPLOS POR PLATAFORMA: ────────────────────────────────────────────────────────────────────────────
🪟 WINDOWS
┌─────────────────────────────────────┐
│ kernel32.dll (Core OS) │
│ user32.dll (Windows/UI) │
│ gdi32.dll (Graphics) │
│ winmm.dll (Multimedia) │
│ dsound.dll (DirectSound) │
│ wasapi.h (Modern audio) │
└─────────────────────────────────────┘
🍎 macOS
┌─────────────────────────────────────┐
│ CoreFoundation (Base utilities) │
│ CoreAudio (Audio system) │
│ CoreMIDI (MIDI) │
│ AudioUnit (Plugin hosting) │
│ Metal (Graphics) │
└─────────────────────────────────────┘
🐧 LINUX
┌─────────────────────────────────────┐
│ libc.so (C standard lib) │
│ libpthread.so (Threading) │
│ libasound.so (ALSA audio) │
│ libjack.so (JACK audio) │
│ libX11.so (X Window System) │
└─────────────────────────────────────┘
Características:
├─ Provided by OS (no download)
├─ Version varies per OS version
├─ Must use for platform features
└─ ABI stability (mostly)
Ventajas:
✅ Always available (if OS supports)
✅ Well-tested
✅ OS integration
Desventajas:
❌ Platform-specific (no portability)
❌ Version varies (OS updates change API)
❌ Limited to OS capabilities
VISUALIZACIÓN DE ACOPLAMIENTO ────────────────────────────────────────────────────────────────────────────
╔═══════════════════════════════════════════════════════════════════════════╗ ║ ║ ║ 🔗 COUPLING SPECTRUM ║ ║ ║ ║ ┌────────────────────────────────────────────────────────────────────┐ ║ ║ │ │ ║ ║ │ TIGHT COUPLING │ ║ ║ │ ═══════════════ │ ║ ║ │ │ │ ║ ║ │ ├─ 📌 Header-only inline │ ║ ║ │ │ └─ Code mezclado directamente en tu compilación │ ║ ║ │ │ Performance: ⭐⭐⭐⭐⭐ │ ║ ║ │ │ Flexibility: ⭐ │ ║ ║ │ │ Update ease: ⭐ │ ║ ║ │ │ │ ║ ║ │ ├─ 🔗 Static linking │ ║ ║ │ │ └─ Binary embebido en ejecutable │ ║ ║ │ │ Performance: ⭐⭐⭐⭐⭐ │ ║ ║ │ │ Flexibility: ⭐⭐ │ ║ ║ │ │ Update ease: ⭐ │ ║ ║ │ │ │ ║ ║ │ ├─ 📦 Dynamic linking │ ║ ║ │ │ └─ Shared library loaded en runtime │ ║ ║ │ │ Performance: ⭐⭐⭐⭐ │ ║ ║ │ │ Flexibility: ⭐⭐⭐ │ ║ ║ │ │ Update ease: ⭐⭐⭐ │ ║ ║ │ │ │ ║ ║ │ ├─ 🔌 Plugin interface │ ║ ║ │ │ └─ Load en runtime via abstraction layer │ ║ ║ │ │ Performance: ⭐⭐⭐ │ ║ ║ │ │ Flexibility: ⭐⭐⭐⭐ │ ║ ║ │ │ Update ease: ⭐⭐⭐⭐ │ ║ ║ │ │ │ ║ ║ │ ├─ 🌐 Network API │ ║ ║ │ │ └─ Service call, no código compartido │ ║ ║ │ │ Performance: ⭐⭐ │ ║ ║ │ │ Flexibility: ⭐⭐⭐⭐⭐ │ ║ ║ │ │ Update ease: ⭐⭐⭐⭐⭐ │ ║ ║ │ │ │ ║ ║ │ LOOSE COUPLING │ ║ ║ │ ══════════════ │ ║ ║ │ │ ║ ║ └────────────────────────────────────────────────────────────────────┘ ║ ║ ║ ║ TRADE-OFFS: ║ ║ ─────────── ║ ║ Tight → Maximum performance, complex updates ║ ║ Medium → Balance, most common ║ ║ Loose → Maximum flexibility, overhead ║ ║ ║ ╚═══════════════════════════════════════════════════════════════════════════╝
🔷 EL GRAFO DE DEPENDENCIAS ────────────────────────────────────────────────────────────────────────────
TEORÍA DE GRAFOS APLICADA: ┌─────────────────────────────────────────────────────────────────────────┐ │ │ │ Un proyecto con dependencies es un GRAFO DIRIGIDO ACÍCLICO (DAG) │ │ │ │ • Nodos = Packages (tu proyecto + dependencies) │ │ • Aristas = "Depends on" relationships │ │ • Dirigido = A → B significa "A necesita B" │ │ • Acíclico = No loops (A → B → C → A ❌) │ │ │ └─────────────────────────────────────────────────────────────────────────┘
🕸️ DEPENDENCY GRAPH ESTRUCTURA ────────────────────────────────────────────────────────────────────────────
EJEMPLO: AudioLab Dependencies
┌──────────────┐
│ AudioLab │
│ (Your app) │
└──────┬───────┘
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
┌───────────┐ ┌──────────┐ ┌──────────┐
│ JUCE │ │ spdlog │ │ Catch2 │
└─────┬─────┘ └────┬─────┘ └──────────┘
│ │
│ ▼
│ ┌──────────┐
│ │ fmt │
│ └──────────┘
│
▼
┌───────────┐
│ FFTW3 │
└───────────┘
INTERPRETACIÓN: ────────────────────────────────────────────────────────────────────────────
DIRECT DEPENDENCIES (AudioLab directamente usa): ├─ JUCE (framework de audio) ├─ spdlog (logging) └─ Catch2 (testing)
TRANSITIVE DEPENDENCIES (dependencies de tus dependencies): ├─ fmt (usado por spdlog) └─ FFTW3 (usado por JUCE para FFT)
TOTAL: 5 packages (1 tuyo + 4 externos)
🎯 PROPIEDADES DEL GRAFO ────────────────────────────────────────────────────────────────────────────
PROPIEDAD 1: ACÍCLICO (NO CYCLES) ────────────────────────────────────────────────────────────────────────────
VÁLIDO: A → B → C → D
INVÁLIDO: A → B → C → A │ ↑ └───────────┘
PROBLEMA: ¿Cuál construir primero?
• A necesita B construido
• B necesita C construido
• C necesita A construido
• DEADLOCK!
DETECCIÓN: • Build systems detectan cycles • Error: "Circular dependency detected" • Solución: Refactor architecture
PROPIEDAD 2: DIRIGIDO (DIRECTION MATTERS) ────────────────────────────────────────────────────────────────────────────
A → B ≠ B → A
A → B significa:
• A depende de B
• A llama funciones de B
• B debe existir para A compile
• B se construye ANTES que A
PROPIEDAD 3: TRANSITIVO ────────────────────────────────────────────────────────────────────────────
Si A → B y B → C, entonces A → C (indirectamente)
IMPLICACIÓN:
• Cambio en C afecta A
• Update C → puede romper A
• Security issue en C → afecta A
• License de C → se propaga a A
🔄 EL DIAMOND PROBLEM ────────────────────────────────────────────────────────────────────────────
PROBLEMA CLÁSICO:
┌──────────────┐
│ AudioLab │
└──────┬───────┘
│
┌────────┴────────┐
│ │
▼ ▼
┌───────────┐ ┌───────────┐
│ LibraryA │ │ LibraryB │
└─────┬─────┘ └─────┬─────┘
│ │
│ ┌───────────┘
│ │
▼ ▼
┌───────────────┐
│ CommonLib │
│ (¿versión?) │
└───────────────┘
CONFLICT: • LibraryA requiere CommonLib v1.0 • LibraryB requiere CommonLib v2.0 • AudioLab necesita AMBOS LibraryA y LibraryB • ¿Qué versión de CommonLib usar?
OPCIONES: ────────────────────────────────────────────────────────────────────────────
OPCIÓN 1: Version Pinning └─ Forzar una versión (ej: v2.0) Puede romper LibraryA si incompatible
OPCIÓN 2: Multiple Versions (Isolation) └─ Static link cada versión Duplicate code, binary size ↑
OPCIÓN 3: Upgrade LibraryA └─ Update/fork LibraryA para usar v2.0 Maintenance burden
OPCIÓN 4: Downgrade LibraryB └─ Si v1.0 es suficiente Feature loss posible
RESOLUCIÓN MODERNA (Package Managers): ────────────────────────────────────────────────────────────────────────────
• Constraint solver intenta encontrar versión compatible
• Si existe overlap en version ranges → usa esa
• Si no existe overlap → ERROR, conflict reportado
• Human decision required
═══════════════════════════════════════════════════════════════════════════════ 🏗️ CAPÍTULO 2: PARADIGMAS DE ADQUISICIÓN ═══════════════════════════════════════════════════════════════════════════════
🔷 SEIS ESTRATEGIAS DE DEPENDENCY MANAGEMENT ────────────────────────────────────────────────────────────────────────────
PREGUNTA FUNDAMENTAL: ┌─────────────────────────────────────────────────────────────────────────┐ │ │ │ ¿Cómo OBTIENE tu proyecto las dependencies que necesita? │ │ │ │ Esta pregunta define tu workflow, reproducibilidad, │ │ y complejidad de setup. │ │ │ └─────────────────────────────────────────────────────────────────────────┘
🗺️ LANDSCAPE DE ESTRATEGIAS ────────────────────────────────────────────────────────────────────────────
┌────────────────────────────────┐
│ DEPENDENCY ACQUISITION │
│ STRATEGIES │
└────────────┬───────────────────┘
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
🏛️ Vendoring 🔍 System 📥 Download Packages on Config │ │ │ ▼ ▼ ▼ 🎯 Package 🏢 Artifact 🔄 Hybrid Manager Repository
🏛️ ESTRATEGIA 1: VENDORING ────────────────────────────────────────────────────────────────────────────
CONCEPTO: "Copiar dependency source code directamente a tu repositorio"
FILOSOFÍA: "Si lo necesito, lo poseo"
ESTRUCTURA: ────────────────────────────────────────────────────────────────────────────
tu_proyecto/
├─ src/
│ ├─ main.cpp
│ └─ ...
├─ include/
│ └─ ...
├─ third_party/ ← Dependencies aquí
│ ├─ fmt/
│ │ ├─ include/
│ │ │ └─ fmt/
│ │ │ └─ *.h
│ │ └─ src/
│ │ └─ *.cc
│ ├─ spdlog/
│ │ └─ include/
│ │ └─ spdlog/
│ └─ json/
│ └─ single_include/
│ └─ nlohmann/
│ └─ json.hpp
└─ CMakeLists.txt
WORKFLOW: ────────────────────────────────────────────────────────────────────────────
1. Developer descarga dependency source
2. Copia a third_party/
3. Commit a Git
4. Build system compila todo junto
5. No external downloads durante build
VENTAJAS: ────────────────────────────────────────────────────────────────────────────
✅ CONTROL TOTAL • Modificar source si necesario • Patch bugs localmente • No depende de external availability
✅ REPRODUCIBILIDAD PERFECTA • Exact version en Git • No "works on my machine" • CI/CD determinístico
✅ NO EXTERNAL FAILURES • GitHub down? No problem • Network issues? Still builds • Package registry offline? Unaffected
✅ OFFLINE-FRIENDLY • Fresh clone builds sin internet • Ideal para airgapped environments
DESVENTAJAS: ────────────────────────────────────────────────────────────────────────────
❌ REPO SIZE GIGANTE • JUCE alone: ~100 MB • FFTW: ~10 MB • Multiple dependencies: cientos de MB • Git history bloats
❌ UPDATES MANUALES • Cada update: manual download • Resolve conflicts en merge • Test compatibility manually • Tedious para many dependencies
❌ DUPLICATE CODE • Si tienes multiple projects • Each vendored separately • Storage waste
❌ LICENSE TRACKING MANUAL • Must track each license • Compliance burden • No automated scanning
APROPIADO CUANDO: ────────────────────────────────────────────────────────────────────────────
├─ Small number of dependencies (< 5)
├─ Critical stability needs
├─ Self-contained distribution requirements
├─ Airgapped / offline environments
└─ Need to patch dependencies frequently
🔍 ESTRATEGIA 2: SYSTEM PACKAGES ────────────────────────────────────────────────────────────────────────────
CONCEPTO: "Usar libraries ya instaladas en el Operating System"
FILOSOFÍA: "El OS provee, yo consumo"
VISUALIZACIÓN: ────────────────────────────────────────────────────────────────────────────
┌─────────────────────────────────────────┐
│ OPERATING SYSTEM │
│ │
│ System Libraries: │
│ ┌─────────────────────────────────┐ │
│ │ /usr/lib/ │ │
│ │ ├─ libfftw3.so.3 │ │
│ │ ├─ libasound.so.2 │ │
│ │ └─ libpulse.so.0 │ │
│ │ │ │
│ │ /usr/include/ │ │
│ │ ├─ fftw3.h │ │
│ │ ├─ alsa/ │ │
│ │ └─ pulse/ │ │
│ └─────────────────────────────────┘ │
└─────────────────┬───────────────────────┘
│
│ find_package(FFTW3)
│
▼
┌─────────────────────────────────────────┐
│ YOUR PROJECT │
│ ├─ Links against /usr/lib/libfftw3.so │
│ └─ Includes /usr/include/fftw3.h │
└─────────────────────────────────────────┘
WORKFLOW: ────────────────────────────────────────────────────────────────────────────
1. User instala dependency via package manager
• Ubuntu: sudo apt install libfftw3-dev
• Fedora: sudo dnf install fftw-devel
• macOS: brew install fftw
2. CMake encuentra library automáticamente
• find_package(FFTW3 REQUIRED)
• Busca en paths standard
3. Link contra system library
• target_link_libraries(app FFTW3::FFTW3)
4. Runtime: OS loader encuentra .so
VENTAJAS: ────────────────────────────────────────────────────────────────────────────
✅ ZERO BLOAT EN REPO • Tu repo solo tiene tu código • Clean Git history • Fast clones
✅ SHARED ENTRE PROYECTOS • Una install, multiple apps usan • Memory shared (solo una copy loaded) • Disk space saved
✅ SECURITY UPDATES AUTOMÁTICOS • OS updates dependency • App gets fixes automatically • No rebuild needed (shared lib)
DESVENTAJAS: ────────────────────────────────────────────────────────────────────────────
❌ VERSION VARIES POR SYSTEM • Ubuntu 20.04: FFTW 3.3.8 • Ubuntu 22.04: FFTW 3.3.10 • Fedora: Different version • Behavior differences posibles
❌ USER MUST INSTALL MANUALLY • README lists dependencies • User must run install commands • Often forgotten • Build fails cryptically
❌ REPRODUCIBILITY DIFÍCIL • "Works on my machine" • CI may have different version • Cross-platform nightmare
❌ NO FUNCIONA CROSS-PLATFORM • Linux: apt/dnf • macOS: brew • Windows: ??? (no standard package manager)
APROPIADO CUANDO: ────────────────────────────────────────────────────────────────────────────
├─ System libraries (OpenGL, ALSA, X11)
├─ Linux-only projects
├─ Power users / developers target audience
├─ Small utility apps
└─ When ABI stability guaranteed
📥 ESTRATEGIA 3: DOWNLOAD ON CONFIGURE ────────────────────────────────────────────────────────────────────────────
CONCEPTO: "CMake FetchContent: descarga durante cmake configure"
FILOSOFÍA: "Just-in-time dependency acquisition"
FLUJO TEMPORAL: ────────────────────────────────────────────────────────────────────────────
┌─────────────────────────────────────────┐
│ cmake -B build │
│ (Configuration phase) │
└──────────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ FetchContent_Declare(fmt) │
│ GIT_REPOSITORY github.com/fmtlib/fmt │
│ GIT_TAG 10.1.1 │
└──────────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ Git clone from GitHub │
│ → build/_deps/fmt-src/ │
└──────────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ FetchContent_MakeAvailable(fmt) │
│ → add_subdirectory() internally │
└──────────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ cmake --build build │
│ Compila fmt junto con tu proyecto │
└─────────────────────────────────────────┘
ESTRUCTURA RESULTANTE: ────────────────────────────────────────────────────────────────────────────
build/
├─ _deps/ ← FetchContent downloads aquí
│ ├─ fmt-src/ ← Source descargado
│ │ ├─ include/
│ │ └─ src/
│ ├─ fmt-build/ ← Compiled objects
│ │ └─ libfmt.a
│ ├─ spdlog-src/
│ └─ spdlog-build/
└─ ...
VENTAJAS: ────────────────────────────────────────────────────────────────────────────
✅ CLEAN REPO (NO VENDORING) • Source repo solo tu código • Git history clean • Small clones
✅ VERSIONING PRECISO • Git tag exact: GIT_TAG 10.1.1 • Commit SHA pinning: GIT_TAG abc123def • Reproducible
✅ AUTOMATIC DOWNLOAD • No manual steps • Fresh checkout → cmake → downloads • Developer-friendly
✅ SOURCE INTEGRATION • Builds junto con proyecto • Same compiler flags • Debug symbols available
DESVENTAJAS: ────────────────────────────────────────────────────────────────────────────
⚠️ CONFIGURE TIME SLOW • Cada cmake configure descarga • Git clone takes time • Multiple dependencies: minutos
⚠️ NETWORK REQUIRED • No internet = no configure • CI failures si GitHub down • Offline development impossible
⚠️ NO BINARY CACHING • Recompiles dependency cada clean build • Slow for large deps (JUCE: 10+ minutos) • CI builds muy lentos
⚠️ BUILD TIME INCREASES • Tu build time + all dependencies • Can dominate compile time
APROPIADO CUANDO: ────────────────────────────────────────────────────────────────────────────
├─ Header-only libraries (fast)
├─ Small dependencies (< 50 files)
├─ Rapid iteration on dependency version
├─ Single developer / small team
└─ Always-online development
🎯 ESTRATEGIA 4: PACKAGE MANAGER (vcpkg) ────────────────────────────────────────────────────────────────────────────
CONCEPTO: "Dedicated C++ package manager con binary caching"
FILOSOFÍA: "NPM/pip for C++"
ARQUITECTURA: ────────────────────────────────────────────────────────────────────────────
┌─────────────────────────────────────────┐
│ vcpkg.json (Manifest Mode) │
│ │
│ { │
│ "dependencies": [ │
│ "juce", │
│ "fmt", │
│ "fftw3" │
│ ] │
│ } │
└──────────────┬──────────────────────────┘
│
│ vcpkg install
│
▼
┌─────────────────────────────────────────┐
│ VCPKG PROCESS │
│ │
│ Para cada dependency: │
│ 1. Download source (from registry) │
│ 2. Apply patches (vcpkg-specific) │
│ 3. Build for your triplet │
│ (x64-windows, x64-linux, etc.) │
│ 4. Install to vcpkg_installed/ │
└──────────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ vcpkg_installed/ │
│ ├─ x64-windows/ │
│ │ ├─ include/ │
│ │ │ ├─ juce/ │
│ │ │ ├─ fmt/ │
│ │ │ └─ fftw3.h │
│ │ └─ lib/ │
│ │ ├─ juce.lib │
│ │ ├─ fmt.lib │
│ │ └─ fftw3.lib │
│ └─ x64-linux/ │
│ └─ ... │
└──────────────┬──────────────────────────┘
│
│ CMake integration
│
▼
┌─────────────────────────────────────────┐
│ find_package(fmt CONFIG REQUIRED) │
│ → Automatically finds in vcpkg_installed│
└─────────────────────────────────────────┘
TRIPLET CONCEPT: ────────────────────────────────────────────────────────────────────────────
TRIPLET = Platform + Architecture + Linkage
EJEMPLOS: ├─ x64-windows (Windows 64-bit, dynamic link) ├─ x64-windows-static (Windows 64-bit, static link) ├─ x64-linux (Linux 64-bit) ├─ x64-osx (macOS Intel) ├─ arm64-osx (macOS Apple Silicon) └─ x86-windows (Windows 32-bit)
Cada triplet = different binary compilation
VENTAJAS: ────────────────────────────────────────────────────────────────────────────
✅ BINARY CACHING (FAST) • Pre-built binaries (if available) • Local cache: ~/.vcpkg/ • CI cache: shared across builds • Download bin vs compile: 100x faster
✅ VERSION LOCKING • vcpkg.json specifies versions • vcpkg-configuration.json (baseline) • Reproducible builds
✅ CROSS-PLATFORM • Same manifest works Win/Mac/Linux • Triplet selects platform • Consistent experience
✅ CONFLICT RESOLUTION • Dependency solver built-in • Detects version conflicts • Suggests resolutions
✅ HUGE REGISTRY • 2000+ packages • Most C++ libraries available • Community-maintained
DESVENTAJAS: ────────────────────────────────────────────────────────────────────────────
⚠️ SETUP OVERHEAD INICIAL • Install vcpkg itself • Bootstrap vcpkg • Integrate with CMake • Learning curve
⚠️ LARGE DOWNLOAD/STORAGE • Binary cache grows (GBs) • Multiple triplets: duplication • Disk space concern
⚠️ VCPKG-SPECIFIC KNOWLEDGE • Triplets, ports, features • Not universal (vcpkg-only) • Team must learn
APROPIADO CUANDO: ────────────────────────────────────────────────────────────────────────────
├─ Multiple large dependencies (> 5)
├─ Professional / team projects
├─ Cross-platform development
├─ CI/CD pipelines (caching crucial)
└─ Long-term maintenance
🎯 AUDIOLAB CHOICE: vcpkg
🏢 ESTRATEGIA 5: ARTIFACT REPOSITORY ────────────────────────────────────────────────────────────────────────────
CONCEPTO: "Internal corporate binary repository"
FILOSOFÍA: "Curated, approved, scanned dependencies"
ARQUITECTURA CORPORATIVA: ────────────────────────────────────────────────────────────────────────────
┌──────────────────────────────────────────────────┐
│ COMPANY ARTIFACTORY / NEXUS │
│ │
│ 📦 Pre-built Binaries: │
│ ├─ juce-7.0.9-x64-windows.zip │
│ ├─ juce-7.0.9-x64-macos.zip │
│ ├─ fftw3-3.3.10-x64-windows.zip │
│ └─ ... │
│ │
│ 🔒 Features: │
│ ├─ Version control │
│ ├─ Access control (authentication) │
│ ├─ Audit logs (who downloaded what) │
│ ├─ Virus scanning │
│ ├─ License compliance checking │
│ └─ Vulnerability scanning │
│ │
└────────────────────┬─────────────────────────────┘
│
│ HTTPS download
│
▼
┌──────────────────────────────────────────────────┐
│ DEVELOPER MACHINES │
│ ├─ Authenticated access │
│ ├─ Fast download (internal network) │
│ └─ Guaranteed clean, approved versions │
└──────────────────────────────────────────────────┘
WORKFLOW: ────────────────────────────────────────────────────────────────────────────
1. Security team curates dependencies
├─ Review license
├─ Scan for vulnerabilities
└─ Approve for use
2. Build team compiles binaries
├─ Consistent compiler/flags
├─ Multiple platforms
└─ Upload to Artifactory
3. Developers download via tool
├─ Custom script or
├─ vcpkg pointed to internal registry
└─ Authenticated
4. Automated updates
├─ Security patches pushed
└─ Teams notified
VENTAJAS: ────────────────────────────────────────────────────────────────────────────
✅ CURATED DEPENDENCIES • Only approved versions • Security vetted • License compliant
✅ SECURITY SCANNING • CVE detection • Automated alerts • Patch enforcement
✅ LICENSE COMPLIANCE • Automated tracking • Audit-ready reports • Legal review
✅ VERY FAST • Internal network speeds • Pre-built binaries • Local mirrors
✅ INTERNAL MIRRORS • No external dependencies • Airgapped environments • Reliability
DESVENTAJAS: ────────────────────────────────────────────────────────────────────────────
❌ INFRASTRUCTURE COST • Servers • Storage (TBs) • Bandwidth
❌ MAINTENANCE OVERHEAD • Team to curate • Build infrastructure • Updates & patches
❌ CORPORATE ONLY • Not for open source • Not for individuals • Overkill for small teams
APROPIADO CUANDO: ────────────────────────────────────────────────────────────────────────────
├─ Large organizations (100+ devs)
├─ Compliance requirements (FDA, ISO)
├─ Multiple teams/products
├─ Security-critical applications
└─ Airgapped / restricted environments
🔄 ESTRATEGIA 6: HYBRID ────────────────────────────────────────────────────────────────────────────
CONCEPTO: "Use the right tool for each dependency"
FILOSOFÍA: "Pragmatic over dogmatic"
EJEMPLO DE ESTRATEGIA HÍBRIDA: ────────────────────────────────────────────────────────────────────────────
┌──────────────────────────────────────────────────┐
│ AUDIOLAB HYBRID STRATEGY │
│ │
│ 🔍 System packages: │
│ ├─ OpenGL (platform graphics) │
│ ├─ pthread (Linux threading) │
│ └─ CoreAudio (macOS audio) │
│ │ │
│ └─ Rationale: OS-provided, stable ABI │
│ │
│ 🎯 vcpkg (package manager): │
│ ├─ JUCE (large framework) │
│ ├─ FFTW3 (complex build) │
│ ├─ spdlog (with dependencies) │
│ └─ Catch2 (testing) │
│ │ │
│ └─ Rationale: Binary caching, versioning │
│ │
│ 📥 FetchContent: │
│ ├─ fmt (header-only mode) │
│ └─ nlohmann/json (single header) │
│ │ │
│ └─ Rationale: Small, fast to download │
│ │
│ 🏛️ Vendoring: │
│ ├─ Custom JUCE modules (patched) │
│ └─ Proprietary SDK wrappers │
│ │ │
│ └─ Rationale: Need modifications, no alt │
│ │
└──────────────────────────────────────────────────┘
DECISION TREE: ────────────────────────────────────────────────────────────────────────────
╔═══════════════════════════════════════════════════════════════════════════╗ ║ ║ ║ 🌳 DEPENDENCY STRATEGY SELECTOR ║ ║ ║ ║ START: Nueva dependency needed ║ ║ │ ║ ║ ├─ ¿Es system library? (OpenGL, pthread, OS APIs) ║ ║ │ └─ SÍ → find_package() system packages ║ ║ │ ║ ║ ├─ ¿Es header-only y small (<10 files)? ║ ║ │ └─ SÍ → FetchContent ║ ║ │ ║ ║ ├─ ¿Necesitas patchear source? ║ ║ │ └─ SÍ → Vendoring (third_party/) ║ ║ │ ║ ║ ├─ ¿Está en vcpkg registry? ║ ║ │ └─ SÍ → vcpkg manifest mode ║ ║ │ ║ ║ ├─ ¿Tienes artifact repository corporativo? ║ ║ │ └─ SÍ → Internal repository ║ ║ │ ║ ║ └─ FALLBACK → FetchContent + custom build ║ ║ ║ ╚═══════════════════════════════════════════════════════════════════════════╝
═══════════════════════════════════════════════════════════════════════════════ ⚖️ CAPÍTULO 3: VERSION RESOLUTION - EL PROBLEMA SAT ═══════════════════════════════════════════════════════════════════════════════
🔷 CONSTRAINT SATISFACTION EN DEPENDENCIES ────────────────────────────────────────────────────────────────────────────
FUNDAMENTO TEÓRICO: ┌─────────────────────────────────────────────────────────────────────────┐ │ │ │ Dependency resolution es un CONSTRAINT SATISFACTION PROBLEM (CSP) │ │ │ │ Variables: Version de cada dependency │ │ Domain: Posibles versions (semver ranges) │ │ Constraints: Compatibility requirements │ │ │ │ Objetivo: Encontrar assignment que satisface ALL constraints │ │ │ │ Complejidad: NP-complete (en general) │ │ │ └─────────────────────────────────────────────────────────────────────────┘
🎯 SCENARIO: VERSION CONFLICTS ────────────────────────────────────────────────────────────────────────────
EJEMPLO PROBLEMÁTICO:
┌──────────────┐
│ AudioLab │
│ v1.0.0 │
└──────┬───────┘
│
┌──────────┴──────────┐
│ │
▼ ▼
┌───────────────┐ ┌───────────────┐
│ JUCE │ │ PluginLib │
│ >= 7.0.0 │ │ v2.3.1 │
└───────────────┘ └───────┬───────┘
│
│ depends on
│
▼
┌───────────────┐
│ JUCE │
│ >= 6.1.0 │
│ < 7.0.0 │
└───────────────┘
ANÁLISIS: ────────────────────────────────────────────────────────────────────────────
AudioLab constraints: ├─ JUCE >= 7.0.0 (necesita features nuevas) └─ PluginLib == 2.3.1 (API específico)
PluginLib constraints: └─ JUCE >= 6.1.0 AND < 7.0.0
COMBINED constraint on JUCE: (>= 7.0.0) AND (>= 6.1.0 AND < 7.0.0)
Simplificando:
>= 7.0.0 AND < 7.0.0
VACÍO! No existe versión que satisfaga ambas.
🚨 CONFLICT DETECTED!
VISUALIZACIÓN DE CONSTRAINT GRAPH: ────────────────────────────────────────────────────────────────────────────
╔═══════════════════════════════════════════════════════════════════════════╗ ║ ║ ║ 🕸️ DEPENDENCY CONSTRAINT GRAPH ║ ║ ║ ║ ║ ║ AudioLab v1.0 ║ ║ │ ║ ║ ┌───────┼───────────────────┐ ║ ║ │ │ │ ║ ║ ▼ ▼ ▼ ║ ║ JUCE >=7.0 fmt ==10.1 spdlog >=1.12 ║ ║ │ │ ║ ║ │ │ ║ ║ │ └──→ fmt >=9.0 ║ ║ │ │ ║ ║ └────────────────┬───────────────────┘ ║ ║ │ ║ ║ CONSTRAINT: ║ ║ fmt version must be ║ ║ >= 10.1 AND >= 9.0 ║ ║ │ ║ ║ INTERSECTION: ║ ║ [10.1, ∞) ║ ║ │ ║ ║ SOLUTION: ║ ║ fmt 10.1.1 ✅ ║ ║ (satisfies both constraints) ║ ║ ║ ║ ────────────────────────────────────────────────────────────────── ║ ║ ║ ║ 🎯 RESOLUTION ALGORITHM: ║ ║ ║ ║ 1️⃣ Collect all version constraints ║ ║ ├─ Direct dependencies ║ ║ └─ Transitive dependencies (recursive) ║ ║ ║ ║ 2️⃣ For each package, find intersection of ranges ║ ║ ├─ [7.0, ∞) ∩ [9.0, ∞) = [9.0, ∞) ║ ║ └─ Use semver comparison logic ║ ║ ║ ║ 3️⃣ If intersection empty → CONFLICT ║ ║ └─ Report error to user ║ ║ ║ ║ 4️⃣ If intersection non-empty → Pick version ║ ║ ├─ Latest in range (default) ║ ║ ├─ Or locked version (if exists) ║ ║ └─ Or user-specified ║ ║ ║ ║ 5️⃣ Recursively resolve dependencies of selected version ║ ║ └─ Depth-first or breadth-first traversal ║ ║ ║ ╚═══════════════════════════════════════════════════════════════════════════╝
🎨 ESTRATEGIAS DE RESOLUTION ────────────────────────────────────────────────────────────────────────────
CUANDO HAY CONFLICT:
🔨 STRATEGY 1: VERSION PINNING (FORCE) ────────────────────────────────────────────────────────────────────────────
ACCIÓN: Forzar versión específica, ignore constraints
┌─────────────────────────────────────┐
│ # Force JUCE 7.0.9 │
│ find_package(JUCE 7.0.9 EXACT) │
└─────────────────────────────────────┘
CONSECUENCIA: ├─ PluginLib espera JUCE 6.x API ├─ JUCE 7 tiene breaking changes ├─ PluginLib puede NO compilar └─ O compilar pero crash en runtime
APROPIADO CUANDO: └─ Sabes que nueva versión es compatible (PluginLib claims <7.0 pero actually works)
🔄 STRATEGY 2: FORK & PATCH ────────────────────────────────────────────────────────────────────────────
ACCIÓN: Fork PluginLib, update su dependency a JUCE 7
┌─────────────────────────────────────┐
│ 1. Fork PluginLib en GitHub │
│ 2. Update JUCE requirement to >=7.0 │
│ 3. Test compatibility │
│ 4. Use forked version │
└─────────────────────────────────────┘
CONSECUENCIA: ├─ Mantienes fork (merge upstream) ├─ Contribution burden ├─ Puede divergir del original └─ Testing overhead
APROPIADO CUANDO: └─ Cambio es pequeño Planning to upstream patch Long-term use of library
🎯 STRATEGY 3: ISOLATION (MULTIPLE VERSIONS) ────────────────────────────────────────────────────────────────────────────
ACCIÓN: Static link diferentes versiones
┌─────────────────────────────────────┐
│ AudioLab core: │
│ ├─ Links JUCE 7.0 (static) │
│ └─ Uses JUCE 7 API │
│ │
│ PluginLib wrapper: │
│ ├─ Links JUCE 6.1 (static) │
│ └─ Isolated namespace │
│ │
│ Final binary: │
│ └─ Contains BOTH versions │
│ (no symbol conflicts) │
└─────────────────────────────────────┘
CONSECUENCIA: ├─ Code duplication (JUCE 2x en binary) ├─ Binary size ↑↑ (puede ser +50 MB) ├─ Memory usage ↑ └─ Complexity in build system
APROPIADO CUANDO: └─ Binary size not critical No other solution viable Temporary measure
💡 STRATEGY 4: COMMUNICATE & WAIT ────────────────────────────────────────────────────────────────────────────
ACCIÓN: Contact PluginLib maintainers
┌─────────────────────────────────────┐
│ 1. Open GitHub issue │
│ 2. Request JUCE 7 support │
│ 3. Offer to help with migration │
│ 4. Wait for update │
└─────────────────────────────────────┘
CONSECUENCIA: ├─ Timeline uncertain (días a meses) ├─ May not happen ├─ Blocks your progress └─ But ideal long-term solution
APROPIADO CUANDO: └─ Not urgent Good relationship with maintainers Community is active
🔷 SEMANTIC VERSIONING - EL LENGUAJE DE VERSIONS ────────────────────────────────────────────────────────────────────────────
📊 SEMVER: MAJOR.MINOR.PATCH ────────────────────────────────────────────────────────────────────────────
STRUCTURE:
v 2 . 4 . 1
│ │ │
│ │ └─ PATCH: Bug fixes
│ │ (backward compatible)
│ │
│ └─ MINOR: New features
│ (backward compatible)
│
└─ MAJOR: Breaking changes
(NOT backward compatible)
🔴 MAJOR VERSION: BREAKING CHANGES ────────────────────────────────────────────────────────────────────────────
TRIGGER EVENTS: ├─ Removed public function/class ├─ Changed function signature ├─ Renamed public API ├─ Changed behavior (incompatible) └─ Removed deprecated features
EXAMPLE: JUCE 6.1.6 → 7.0.0
BEFORE (6.x):
┌────────────────────────────────────┐
│ class AudioProcessor { │
│ virtual void processBlock( │
│ AudioBuffer<float>& buffer, │
│ MidiBuffer& midi │
│ ); │
│ } │
└────────────────────────────────────┘
AFTER (7.x):
┌────────────────────────────────────┐
│ class AudioProcessor { │
│ virtual void processBlock( │
│ AudioBuffer<float>& buffer, │
│ MidiBuffer& midi, │
│ AudioPlayHead* playhead ← NEW │
│ ); │
│ } │
└────────────────────────────────────┘
USER IMPACT:
├─ Code must be updated
├─ Recompile required
├─ Manual migration
└─ Testing needed
🟡 MINOR VERSION: NEW FEATURES ────────────────────────────────────────────────────────────────────────────
TRIGGER EVENTS: ├─ Added new public function ├─ Added new optional parameter (default value) ├─ Deprecated old API (not removed) └─ New functionality (opt-in)
EXAMPLE: fmt 10.0.0 → 10.1.0
NEW FEATURE:
┌────────────────────────────────────┐
│ // New function added │
│ std::string fmt::format_to_string( │
│ const char* fmt, │
│ Args... args │
│ ); │
└────────────────────────────────────┘
USER IMPACT:
├─ Old code still works (no changes)
├─ Can use new features if want
├─ Safe to upgrade
└─ No breaking changes
🟢 PATCH VERSION: BUG FIXES ────────────────────────────────────────────────────────────────────────────
TRIGGER EVENTS: ├─ Fixed crash ├─ Corrected calculation error ├─ Fixed memory leak ├─ Documentation typos └─ Performance improvements (no API change)
EXAMPLE: spdlog 1.12.0 → 1.12.1
FIX:
┌────────────────────────────────────┐
│ // BEFORE: Memory leak │
│ logger->log(...); │
│ // buffer not freed │
│ │
│ // AFTER: Fixed │
│ logger->log(...); │
│ // buffer properly freed │
└────────────────────────────────────┘
USER IMPACT:
├─ Always safe to upgrade
├─ Only fixes, no new features
├─ No code changes needed
└─ Recommended to update
VERSION RANGE OPERATORS ────────────────────────────────────────────────────────────────────────────
╔═══════════════════════════════════════════════════════════════════════════╗ ║ ║ ║ 🎯 VERSION SPECIFIERS ║ ║ ║ ╠═══════════════════════════════════════════════════════════════════════════╣ ║ ║ ║ SPECIFIER │ MEANING │ USE CASE ║ ╠═══════════════════════════════════════════════════════════════════════════╣ ║ ║ ║ ==2.3.1 │ Exact version │ Critical stability ║ ║ │ Only 2.3.1 │ Known good version ║ ║ │ │ Tested thoroughly ║ ║ │ │ ║ ║ Example range: [2.3.1] ║ ║ ║ ║ ────────────────────────────────────────────────────────────────── ║ ║ ║ ║ ^2.3.1 │ Compatible release │ DEFAULT choice ║ ║ (Caret) │ >= 2.3.1 and < 3.0.0 │ Get bug fixes ║ ║ │ Minor/patch OK │ Not breaking changes ║ ║ │ Major NO │ ║ ║ │ │ ║ ║ Example range: [2.3.1, 3.0.0) ║ ║ 2.3.1 ✅ 2.4.0 ✅ 2.99.0 ✅ 3.0.0 ❌ ║ ║ ║ ║ ────────────────────────────────────────────────────────────────── ║ ║ ║ ║ ~2.3.1 │ Patch changes │ Conservative ║ ║ (Tilde) │ >= 2.3.1 and < 2.4.0 │ Only bug fixes ║ ║ │ Patch OK │ No new features ║ ║ │ Minor NO │ ║ ║ │ │ ║ ║ Example range: [2.3.1, 2.4.0) ║ ║ 2.3.1 ✅ 2.3.5 ✅ 2.4.0 ❌ ║ ║ ║ ║ ────────────────────────────────────────────────────────────────── ║ ║ ║ ║ >=2.3.1 │ Minimum version │ Need specific feature ║ ║ │ Any >= 2.3.1 │ Added in 2.3.1 ║ ║ │ No upper limit │ Flexible ║ ║ │ │ ║ ║ Example range: [2.3.1, ∞) ║ ║ 2.3.1 ✅ 3.0.0 ✅ 10.0.0 ✅ ║ ║ ║ ║ ────────────────────────────────────────────────────────────────── ║ ║ ║ ║ >2.3.1,<3.0 │ Explicit range │ Known incompatibility ║ ║ │ Between two versions │ Specific constraints ║ ║ │ │ ║ ║ Example range: (2.3.1, 3.0.0) ║ ║ 2.3.1 ❌ 2.5.0 ✅ 3.0.0 ❌ ║ ║ ║ ╚═══════════════════════════════════════════════════════════════════════════╝
RECOMENDACIONES: ────────────────────────────────────────────────────────────────────────────
DEFAULT: Use ^X.Y.Z (caret) ├─ Permite bug fixes (patch) ├─ Permite new features (minor) ├─ Bloquea breaking changes (major) └─ Balance entre stability y updates
CONSERVATIVE: Use ~X.Y.Z (tilde) ├─ Solo bug fixes ├─ Maximum stability └─ Cuando stability > features
FLEXIBLE: Use >=X.Y.Z ├─ Need specific feature from X.Y.Z ├─ Trust library to not break └─ Rolling updates
PINNED: Use ==X.Y.Z ├─ Critical production code ├─ Extensively tested version └─ Manual update process
═══════════════════════════════════════════════════════════════════════════════ 🔒 CAPÍTULO 4: REPRODUCIBILIDAD - EL SANTO GRIAL ═══════════════════════════════════════════════════════════════════════════════
🔷 ¿QUÉ ES REPRODUCIBILIDAD? ────────────────────────────────────────────────────────────────────────────
DEFINICIÓN: ┌─────────────────────────────────────────────────────────────────────────┐ │ │ │ REPRODUCIBILIDAD = Capacidad de obtener el MISMO binario │ │ exacto dado el mismo source code │ │ │ │ Ideal: BIT-FOR-BIT identical builds │ │ │ │ Por qué importa: │ │ ├─ Debugging: "Works on my machine" eliminated │ │ ├─ Security: Verify build integrity │ │ ├─ Compliance: Audit trail │ │ └─ Collaboration: Same environment todos │ │ │ └─────────────────────────────────────────────────────────────────────────┘
FACTORES QUE AFECTAN REPRODUCIBILIDAD: ────────────────────────────────────────────────────────────────────────────
├─ 📦 Dependency versions
├─ 🔧 Compiler version/flags
├─ 🖥️ Operating system version
├─ 🌐 Network state (if downloads)
├─ ⏰ Build time (timestamps)
└─ 🎲 Randomness (ASLR, etc.)
🎯 NIVELES DE REPRODUCIBILIDAD ────────────────────────────────────────────────────────────────────────────
PYRAMID DE REPRODUCIBILIDAD: ────────────────────────────────────────────────────────────────────────────
┌──────────────────┐
│ NIVEL 4 │
│ HERMETIC │
│ (Perfecto) │
└────────┬─────────┘
│
┌────────▼─────────┐
│ NIVEL 3 │
│ LOCK FILE │
│ (Muy bueno) │
└────────┬─────────┘
│
┌────────▼─────────┐
│ NIVEL 2 │
│ DOCUMENTATION │
│ (Básico) │
└────────┬─────────┘
│
┌────────▼─────────┐
│ NIVEL 1 │
│ AD-HOC │
│ (Frágil) │
└────────┬─────────┘
│
┌────────▼─────────┐
│ NIVEL 0 │
│ CHAOS │
│ (Imposible) │
└──────────────────┘
🔴 NIVEL 0: CHAOS (NO REPRODUCIBILITY) ────────────────────────────────────────────────────────────────────────────
CARACTERÍSTICAS: ├─ "Install dependencies somehow" ├─ No version specification ├─ Undocumented setup └─ Cada developer por su cuenta
SCENARIO: ────────────────────────────────────────────────────────────────────────────
Developer A:
├─ Windows 10
├─ MSVC 2019
├─ JUCE 6.1.6 (whatever was latest cuando instaló)
├─ Downloaded FFTW from random website
└─ "It compiles on my machine!"
Developer B:
├─ macOS Ventura
├─ Xcode 14 (Clang)
├─ JUCE 7.0.2 (latest today)
├─ brew install fftw (whatever brew has)
└─ Compilation errors
CI Server:
├─ Ubuntu 22.04
├─ GCC 11
├─ JUCE 7.0.5 (CI cached version)
├─ apt install libfftw3-dev (old version)
└─ Different behavior, mysterious bugs
PROBLEMA: 💥 Different results en cada environment 💥 "Works on my machine™" syndrome 💥 Debugging impossible 💥 No way to reproduce bugs
🟡 NIVEL 1: DOCUMENTATION ────────────────────────────────────────────────────────────────────────────
CARACTERÍSTICAS: ├─ README lists dependency versions ├─ Manual installation instructions ├─ Human-enforced consistency └─ Better than nothing
EJEMPLO: ────────────────────────────────────────────────────────────────────────────
README.md:
┌─────────────────────────────────────┐
│ # Dependencies │
│ │
│ Please install: │
│ - JUCE 7.0.9 │
│ - FFTW 3.3.10 │
│ - fmt 10.1.1 │
│ - spdlog 1.12.0 │
│ │
│ ## Installation │
│ ...manual steps... │
└─────────────────────────────────────┘
PROBLEMAS: ⚠️ Manual process (error-prone) ⚠️ Easy to forget/skip ⚠️ Documentation drifts from reality ⚠️ No automated enforcement
BENEFICIO: ✅ At least documented ✅ New developers have guide ✅ Better than LEVEL 0
🟢 NIVEL 2: LOCK FILE ────────────────────────────────────────────────────────────────────────────
CARACTERÍSTICAS: ├─ Machine-readable dependency manifest ├─ Exact versions captured ├─ Automated installation └─ Enforced consistency
TECNOLOGÍAS: ├─ vcpkg: vcpkg.json + vcpkg-lock.json ├─ Conan: conanfile.txt + conan.lock └─ NPM analogy: package.json + package-lock.json
EJEMPLO: vcpkg Manifest Mode ────────────────────────────────────────────────────────────────────────────
vcpkg.json (MANIFEST):
┌─────────────────────────────────────┐
│ { │
│ "dependencies": [ │
│ { │
│ "name": "juce", │
│ "version>=": "7.0.9" │
│ }, │
│ { │
│ "name": "fftw3", │
│ "version>=": "3.3.10" │
│ } │
│ ] │
│ } │
└─────────────────────────────────────┘
vcpkg-configuration.json (BASELINE):
┌─────────────────────────────────────┐
│ { │
│ "default-registry": { │
│ "kind": "git", │
│ "repository": "microsoft/vcpkg",│
│ "baseline": "abc123..." │
│ } │
│ } │
└─────────────────────────────────────┘
BASELINE = Git commit SHA del vcpkg registry
├─ Locks ALL package versions
├─ Exact reproducibility
└─ Versioned in Git
WORKFLOW: ────────────────────────────────────────────────────────────────────────────
Developer A:
1. git clone project
2. cmake -B build
(vcpkg installs exact versions from manifest)
3. cmake --build build
Developer B (different machine):
1. git clone project
2. cmake -B build
(vcpkg installs SAME versions)
3. cmake --build build
Result: IDENTICAL dependencies ✅
BENEFICIOS: ────────────────────────────────────────────────────────────────────────────
✅ AUTOMATIC ENFORCEMENT • No human error • Consistent across team • CI uses same versions
✅ SAME VERSIONS GUARANTEED • Lock file commits SHA hashes • Bit-for-bit same source • Reproducible
✅ EASY UPDATES • Update manifest • Re-lock • Controlled, versioned
LIMITACIONES: ────────────────────────────────────────────────────────────────────────────
⚠️ COMPILER NOT LOCKED • Developer A: GCC 11 • Developer B: GCC 13 • Different optimization bugs possible
⚠️ OS NOT LOCKED • Ubuntu vs Fedora • macOS vs Linux • System library differences
⚠️ TIMESTAMP VARIATIONS • Build time embedded • Not bit-for-bit identical • But functionally equivalent
🔵 NIVEL 3: HERMETIC BUILD ────────────────────────────────────────────────────────────────────────────
CARACTERÍSTICAS: ├─ COMPLETE environment capture ├─ OS, compiler, tools ALL locked ├─ Isolated from host system └─ Perfect reproducibility
TECNOLOGÍA: Docker / Containers ────────────────────────────────────────────────────────────────────────────
Dockerfile:
┌──────────────────────────────────────────┐
│ # Exact base OS │
│ FROM ubuntu:22.04 │
│ │
│ # Exact compiler version │
│ RUN apt-get update && \ │
│ apt-get install -y \ │
│ gcc-11=11.4.0-1ubuntu1~22.04 │
│ g++-11=11.4.0-1ubuntu1~22.04 │
│ cmake=3.22.1-1ubuntu1.22.04.1 │
│ │
│ # Exact tool versions │
│ RUN apt-get install -y \ │
│ git=1:2.34.1-1ubuntu1.10 │
│ ninja-build=1.10.1-1 │
│ │
│ # vcpkg at exact commit │
│ RUN git clone https://github.com/\ │
│ microsoft/vcpkg.git && \ │
│ cd vcpkg && \ │
│ git checkout abc123def456 │
│ │
│ # Environment variables │
│ ENV VCPKG_ROOT=/vcpkg │
│ ENV PATH="${VCPKG_ROOT}:${PATH}" │
│ │
│ # Build script │
│ COPY . /src │
│ WORKDIR /src │
│ RUN cmake -B build && \ │
│ cmake --build build │
└──────────────────────────────────────────┘
GARANTÍAS: ────────────────────────────────────────────────────────────────────────────
✅ IDENTICAL ENVIRONMENT • Same OS version (Ubuntu 22.04) • Same kernel (virtualized) • Same filesystem layout
✅ IDENTICAL TOOLCHAIN • GCC 11.4.0 exact • CMake 3.22.1 exact • All tools versioned
✅ ISOLATED FROM HOST • No host contamination • Clean build every time • No "works on my machine"
✅ PERFECT REPRODUCIBILITY • Same input → Same output • Bit-for-bit identical (casi) • Auditability
WORKFLOW: ────────────────────────────────────────────────────────────────────────────
Developer (any OS):
1. docker build -t audiolab-build .
2. docker run audiolab-build
3. Binary in container
CI/CD:
1. docker build -t audiolab-build .
2. docker run audiolab-build
3. Extract artifacts
GUARANTEE: Same Docker image → same binary
LIMITACIONES: ────────────────────────────────────────────────────────────────────────────
⚠️ TIMESTAMPS • Build time still varies • Can strip for true reproducibility
⚠️ PERFORMANCE • Slower (virtualization overhead) • Storage (Docker images GB)
⚠️ COMPLEXITY • Dockerfile maintenance • Learning curve • Debugging harder
🔐 HASH CHAINS PARA VERIFICATION ────────────────────────────────────────────────────────────────────────────
CONCEPTO: Cada dependency tiene hash criptográfico Verifica integridad end-to-end
CHAIN OF TRUST: ────────────────────────────────────────────────────────────────────────────
╔═══════════════════════════════════════════════════════════════════════════╗ ║ ║ ║ 🔐 CRYPTOGRAPHIC VERIFICATION ║ ║ ║ ║ ┌─────────────────────────────────────────────────────────────────┐ ║ ║ │ PACKAGE REGISTRY (vcpkg, etc.) │ ║ ║ │ │ ║ ║ │ Package: juce-7.0.9.tar.gz │ ║ ║ │ SHA256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca... │ ║ ║ │ ↑ │ ║ ║ │ │ Computed by registry │ ║ ║ │ │ Signed by maintainers │ ║ ║ └───────────┼─────────────────────────────────────────────────────┘ ║ ║ │ ║ ║ │ Download ║ ║ │ ║ ║ ▼ ║ ║ ┌─────────────────────────────────────────────────────────────────┐ ║ ║ │ YOUR BUILD SYSTEM │ ║ ║ │ │ ║ ║ │ 1. Download juce-7.0.9.tar.gz │ ║ ║ │ 2. Compute SHA256 of downloaded file │ ║ ║ │ 3. Compare with registry hash │ ║ ║ │ │ ║ ║ │ IF match: │ ║ ║ │ ✅ File authentic, not tampered │ ║ ║ │ ✅ Proceed with build │ ║ ║ │ │ ║ ║ │ IF no match: │ ║ ║ │ ❌ File corrupted or malicious │ ║ ║ │ ❌ ABORT build │ ║ ║ │ ❌ Alert user │ ║ ║ └─────────────────────────────────────────────────────────────────┘ ║ ║ ║ ║ SECURITY BENEFITS: ║ ║ ├─ Detect file corruption (network errors) ║ ║ ├─ Detect tampering (MITM attacks) ║ ║ ├─ Verify source authenticity ║ ║ └─ Audit trail (what was used) ║ ║ ║ ╚═══════════════════════════════════════════════════════════════════════════╝
IMPLEMENTATION: ────────────────────────────────────────────────────────────────────────────
vcpkg EXAMPLE:
vcpkg installs port:
1. Read portfile (build recipe)
2. Download source tarball
3. Verify SHA512 hash
4. If mismatch → ERROR, abort
5. If match → proceed to build
MANIFEST Example: ┌─────────────────────────────────────┐ │ { │ │ "name": "my-custom-lib", │ │ "version": "1.0.0", │ │ "homepage": "...", │ │ "$expected-sha": { │ │ "source": { │ │ "url": "github.com/.../v1.0", │ │ "sha512": "abc123def456..." │ │ } │ │ } │ │ } │ └─────────────────────────────────────┘
═══════════════════════════════════════════════════════════════════════════════ 🎯 CAPÍTULO 5: AUDIOLAB DEPENDENCY STRATEGY ═══════════════════════════════════════════════════════════════════════════════
🔷 DECISIONES DE ARQUITECTURA ────────────────────────────────────────────────────────────────────────────
╔═══════════════════════════════════════════════════════════════════════════╗ ║ ║ ║ 🎵 AUDIOLAB DEPENDENCY ARCHITECTURE ║ ║ ║ ╠═══════════════════════════════════════════════════════════════════════════╣ ║ ║ ║ PRIMARY STRATEGY: vcpkg Manifest Mode ║ ║ ═════════════════════════════════════ ║ ║ ║ ║ Rationale: ║ ║ ├─ ✅ Binary caching (faster CI/CD) ║ ║ ├─ ✅ Cross-platform (Win/Mac/Linux) ║ ║ ├─ ✅ Version locking (reproducibility) ║ ║ ├─ ✅ Large dependencies (JUCE, FFTW handle well) ║ ║ ├─ ✅ Team collaboration (shared manifest) ║ ║ └─ ✅ Industry standard (Microsoft-backed) ║ ║ ║ ╠═══════════════════════════════════════════════════════════════════════════╣ ║ ║ ║ DEPENDENCY CATALOG ║ ║ ══════════════════ ║ ║ ║ ║ 🎨 JUCE Framework ║ ║ ─────────────────── ║ ║ Version: 7.0.9+ (^7.0.9) ║ ║ Source: vcpkg ║ ║ Linkage: Static ║ ║ Features: vst3, au, standalone ║ ║ Purpose: Core plugin framework ║ ║ Critical: YES (entire architecture depends) ║ ║ Update: Conservative (quarterly) ║ ║ ║ ║ Justification: ║ ║ • Industry standard para audio plugins ║ ║ • Cross-platform abstractions ║ ║ • Plugin format wrappers (VST3, AU, AAX) ║ ║ • Extensive audio utilities ║ ║ ║ ║ ────────────────────────────────────────────────────────────────── ║ ║ ║ ║ 📊 FFTW3 (Fastest Fourier Transform in the West) ║ ║ ───────────────────────────────────────────────── ║ ║ Version: 3.3.10 ║ ║ Source: vcpkg ║ ║ Linkage: Static ║ ║ Options: SSE2, AVX optimizations ║ ║ Purpose: FFT operations (spectral processing) ║ ║ Critical: YES (performance-critical DSP) ║ ║ Update: Stable (rarely changes) ║ ║ ║ ║ Justification: ║ ║ • Best-in-class FFT performance ║ ║ • SIMD optimizations (critical for real-time) ║ ║ • Proven stability ║ ║ • Used by professional audio industry ║ ║ ║ ║ ────────────────────────────────────────────────────────────────── ║ ║ ║ ║ 📝 fmt (Formatting Library) ║ ║ ────────────────────────── ║ ║ Version: 10.1.1 (^10.1.0) ║ ║ Source: vcpkg (header-only mode) ║ ║ Linkage: Header-only ║ ║ Purpose: String formatting, logging support ║ ║ Critical: NO (utility) ║ ║ Update: Regular (monthly) ║ ║ ║ ║ Justification: ║ ║ • Type-safe printf alternative ║ ║ • Better than std::format (not all compilers) ║ ║ • Required by spdlog ║ ║ • Fast compile times ║ ║ ║ ║ ────────────────────────────────────────────────────────────────── ║ ║ ║ ║ 📋 spdlog (Fast C++ Logging) ║ ║ ──────────────────────────── ║ ║ Version: 1.12.0 (^1.12.0) ║ ║ Source: vcpkg ║ ║ Linkage: Static ║ ║ Depends: fmt >=9.0 ║ ║ Purpose: Logging infrastructure ║ ║ Critical: NO (debugging aid) ║ ║ Update: Regular (monthly) ║ ║ ║ ║ Justification: ║ ║ • Fast, header-only option ║ ║ • Asynchronous logging (doesn't block audio thread) ║ ║ • Multiple sinks (file, console, custom) ║ ║ • Pattern formatting ║ ║ ║ ║ ────────────────────────────────────────────────────────────────── ║ ║ ║ ║ 🧪 Catch2 (Testing Framework) ║ ║ ───────────────────────────── ║ ║ Version: 3.4.0 (^3.4.0) ║ ║ Source: vcpkg ║ ║ Linkage: Static ║ ║ Purpose: Unit testing ║ ║ Critical: NO (dev/test only) ║ ║ Update: Regular (monthly) ║ ║ ║ ║ Justification: ║ ║ • Modern C++ testing (C++14+) ║ ║ • BDD-style tests ║ ║ • Excellent error messages ║ ║ • Industry standard ║ ║ ║ ║ ────────────────────────────────────────────────────────────────── ║ ║ ║ ║ 📈 Google Benchmark ║ ║ ────────────────────── ║ ║ Version: 1.8.3 ║ ║ Source: vcpkg ║ ║ Linkage: Static ║ ║ Purpose: Performance benchmarking ║ ║ Critical: NO (dev only) ║ ║ Update: Stable (quarterly) ║ ║ ║ ║ Justification: ║ ║ • Accurate microbenchmarks ║ ║ • Statistical analysis ║ ║ • Regression detection ║ ║ • Industry standard (Google) ║ ║ ║ ╚═══════════════════════════════════════════════════════════════════════════╝
DEPENDENCY GRAPH AUDIOLAB: ────────────────────────────────────────────────────────────────────────────
┌──────────────┐
│ AudioLab │
└──────┬───────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
┌───────────────┐ ┌──────────────┐ ┌──────────────┐
│ JUCE │ │ spdlog │ │ Catch2 │
│ 7.0.9+ │ │ 1.12.0 │ │ 3.4.0 │
└───────┬───────┘ └──────┬───────┘ └──────────────┘
│ │
▼ ▼
┌───────────────┐ ┌──────────────┐
│ FFTW3 │ │ fmt │
│ 3.3.10 │ │ 10.1.1 │
└───────────────┘ └──────────────┘
TOTAL: 5 dependencies (direct + transitive)
FALLBACK STRATEGIES: ────────────────────────────────────────────────────────────────────────────
╔═══════════════════════════════════════════════════════════════════════════╗ ║ ║ ║ 🔄 FALLBACK STRATEGY: FetchContent ║ ║ ────────────────────────────────── ║ ║ ║ ║ Para dependencies NO en vcpkg registry: ║ ║ ║ ║ ├─ Custom JUCE modules (experimental) ║ ║ │ └─ FetchContent_Declare(custom-juce-module ...) ║ ║ │ ║ ║ ├─ Proprietary SDKs (AAX SDK) ║ ║ │ └─ Manual download + CMake ExternalProject ║ ║ │ ║ ║ └─ Experimental/unreleased libraries ║ ║ └─ Git submodule + add_subdirectory() ║ ║ ║ ╠═══════════════════════════════════════════════════════════════════════════╣ ║ ║ ║ 🏛️ VENDORING STRATEGY: Minimal ║ ║ ──────────────────────────────── ║ ║ ║ ║ Solo para casos excepcionales: ║ ║ ║ ║ ├─ Single-header utilities (stb_image, etc.) ║ ║ │ └─ third_party/stb/stb_image.h ║ ║ │ ║ ║ ├─ Patched versions critical ║ ║ │ └─ Custom fork con bug fix urgent ║ ║ │ ║ ║ └─ License-embedded code (public domain) ║ ║ └─ Small utilities < 500 lines ║ ║ ║ ╚═══════════════════════════════════════════════════════════════════════════╝
DEPENDENCY UPDATE POLICY ────────────────────────────────────────────────────────────────────────────
📅 UPDATE CADENCE STRATEGY ────────────────────────────────────────────────────────────────────────────
🔴 CRITICAL SECURITY PATCHES ────────────────────────────────────────────────────────────────────────────
TRIGGER: ├─ CVE publicado afecta dependency ├─ Security advisory de vendor └─ Vulnerability scan alerta
UPDATE TIMELINE: IMMEDIATE (< 24 hours)
PROCESS: 1. Security team notifica 2. Review CVE severity (CVSS score) 3. Update version en vcpkg.json 4. Test critical paths (automated suite) 5. Deploy hotfix if production affected 6. Document en security log
TESTING: ├─ Automated unit tests (must pass) ├─ Integration tests (must pass) ├─ Manual smoke test (plugin loads) └─ Regression test (if time permits)
🟡 MINOR/PATCH UPDATES ────────────────────────────────────────────────────────────────────────────
TRIGGER: ├─ Monthly dependency review ├─ Bug fixes available └─ Performance improvements
UPDATE TIMELINE: MONTHLY (scheduled)
PROCESS: 1. Review changelogs de all dependencies 2. Identify safe updates (patch/minor) 3. Update vcpkg.json versions 4. Re-lock baseline 5. Full test suite execution 6. Regression testing 7. Merge via PR (code review)
TESTING: ├─ Full automated test suite ├─ Performance benchmarks ├─ Integration tests (all platforms) └─ Manual QA (critical features)
ROLLBACK PLAN: └─ If tests fail, revert vcpkg.json Document issue Open bug report upstream
🔵 MAJOR VERSION UPDATES ────────────────────────────────────────────────────────────────────────────
TRIGGER: ├─ New features needed ├─ Quarterly planned review └─ End-of-life (EOL) of current version
UPDATE TIMELINE: QUARTERLY (planned, deliberate)
PROCESS: 1. Research breaking changes (read migration guide) 2. Assess impact (grep codebase for affected APIs) 3. Create migration plan (document changes needed) 4. Create feature branch (not main) 5. Update dependency version 6. Fix compilation errors 7. Fix runtime behavior changes 8. Update tests 9. Extensive testing (all platforms) 10. Code review (team) 11. Beta testing (internal) 12. Merge to main
TESTING: ├─ Full test suite (all configs) ├─ Performance benchmarks (no regression) ├─ Integration tests (all plugin formats) ├─ Manual QA (full feature matrix) ├─ Beta period (1 week minimum) └─ Real-world usage (dogfooding)
EFFORT ESTIMATE: 1-2 weeks engineering time
ROLLBACK PLAN: └─ Feature branch allows easy rollback Main unaffected until merge
═══════════════════════════════════════════════════════════════════════════════ 💡 CONCLUSIÓN: DEPENDENCIES COMO INFRAESTRUCTURA CRÍTICA ═══════════════════════════════════════════════════════════════════════════════
🎯 PRINCIPIOS FILOSÓFICOS ────────────────────────────────────────────────────────────────────────────
┌─────────────────────────────────────────────────────────────────────────┐ │ │ │ 1️⃣ Dependencies ≠ Free Lunch │ │ ───────────────────────────── │ │ │ │ Cada dependency trae: │ │ ├─ ✅ Functionality (no reinventar rueda) │ │ ├─ ✅ Expertise (mejor que tu implementación) │ │ ├─ ✅ Mantenimiento (bug fixes gratis) │ │ │ │ │ Pero también: │ │ ├─ ❌ Coupling (dependes de decisiones ajenas) │ │ ├─ ❌ Vulnerabilities (supply chain attacks) │ │ ├─ ❌ Maintenance burden (updates, conflicts) │ │ ├─ ❌ Size/complexity (binary bloat) │ │ └─ ❌ License obligations (compliance) │ │ │ │ EVALUACIÓN: Cada dependency debe justificarse. │ │ Benefit > Cost │ │ │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ 2️⃣ Version Locking = Stability │ │ ──────────────────────────── │ │ │ │ Floating versions ("latest") = Chaos │ │ Locked versions = Reproducibility │ │ │ │ Lock file (vcpkg-lock.json) es NON-NEGOTIABLE │ │ para proyectos profesionales. │ │ │ │ Permite: │ │ ├─ Bisect bugs (saber qué versión causó) │ │ ├─ Rollback (volver a working state) │ │ └─ Audits (compliance & security) │ │ │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ 3️⃣ Reproducibility = Professionalism │ │ ────────────────────────────────────── │ │ │ │ "Works on my machine" es amateur. │ │ │ │ Professional projects garantizan: │ │ ├─ Same dependencies → Same build │ │ ├─ Any developer → Same environment │ │ ├─ CI/CD → Identical to local │ │ └─ 6 months later → Still builds │ │ │ │ Herramientas: │ │ ├─ Lock files (vcpkg-lock.json) │ │ ├─ Docker (hermetic builds) │ │ └─ Hash verification (integrity) │ │ │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ 4️⃣ Update Strategy = Risk Management │ │ ───────────────────────────────────── │ │ │ │ Updates NO son automáticos. │ │ Cada update es decisión consciente. │ │ │ │ Clasificación: │ │ ├─ Security: URGENT (< 24h) │ │ ├─ Patch/Minor: REGULAR (monthly) │ │ └─ Major: PLANNED (quarterly) │ │ │ │ Testing proporcional a risk: │ │ ├─ Patch: Smoke tests │ │ ├─ Minor: Full suite │ │ └─ Major: Extensive QA │ │ │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ 5️⃣ Tool Choice = Long-term Investment │ │ ────────────────────────────────────── │ │ │ │ Dependency management system es FOUNDATION. │ │ Cambiar después = VERY expensive. │ │ │ │ Criteria: │ │ ├─ Cross-platform (Win/Mac/Linux) │ │ ├─ Active maintenance (not abandoned) │ │ ├─ Large ecosystem (package availability) ║ │ ├─ Industry adoption (hiring, support) │ │ └─ Integration (CMake, IDEs) │ │ │ │ AudioLab choice: vcpkg │ │ ├─ Microsoft-backed (longevity) │ │ ├─ CMake-first (our build system) │ │ ├─ Binary caching (CI performance) │ │ └─ Growing ecosystem (2000+ packages) │ │ │ └─────────────────────────────────────────────────────────────────────────┘
SÍNTESIS FINAL: ────────────────────────────────────────────────────────────────────────────
Dependencies
│
┌────────────┴────────────┐
│ │
ASSET LIABILITY
│ │
┌───────┴───────┐ ┌───────┴───────┐
│ │ │ │
Functionality Expertise Coupling Maintenance
(Don't (Better (Lock-in) (Updates,
reinvent) than you) conflicts)
│ │ │ │
└───────┬───────┘ └───────┬───────┘
│ │
BENEFIT COST
│ │
└────────────┬────────────┘
│
EVALUATION:
Maximize benefit
Minimize cost
│
STRATEGIES:
├─ Careful selection
├─ Version locking
├─ Update policy
└─ Reproducibility
═══════════════════════════════════════════════════════════════════════════════ FIN DEL DOCUMENTO ═══════════════════════════════════════════════════════════════════════════════
"Dependencies are the foundation upon which we build. Choose wisely, manage carefully, update deliberately." 📦