Cosa dovrei preferire: un sotto -posto o un progetto esterno CMake?

Question

Cosa dovrei preferire: un sotto -posto o un progetto esterno CMake?

#1 da (0 voti)

1

Sto sviluppando o mantenendo un progetto software gratuito Foo che utilizza CMake per un sistema di compilazione, oltre al controllo del codice sorgente (ad esempio Mercurial o Git), con il repository disponibile online.

Ora, questo progetto dipende da un altro progetto, Bar - per esempio, utilizza i file include forniti da questo altro progetto. La barra esiste indipendentemente, ed è anche FOSS e disponibile da un repository pubblico di controllo delle fonti.

Ora, CMake ha un meccanismo per scaricare, configurare e costruire tali sottoprogetti: ExternalProject . Tuttavia, potrei anche fare in modo che Bar sia un sotto-repository del repository Foo source, in modo che venga estratto insieme a Foo e CMake possa trattare la composizione di file e cartelle estratti come se fosse una sola gerarchia di file.

Consiglieresti un approccio rispetto all'altro, generalmente? In caso contrario, quali sono le considerazioni per la scelta di un'opzione rispetto all'altra?

version-control repository cmake

posta einpoklum 05.11.2018 - 22:25

fonte

1 risposta

Leggi altre domande sui tag version-control repository cmake

Microservices e "Master Data Management" - sono compatibili? Condividi alcuni piccoli bit di funzionalità tra i pacchetti

score 0 · Answer 1

La vendita di un altro progetto può essere una misura adatta per il periodo di pausa in assenza di uno strumento di gestione delle dipendenze adatto. In particolare, il funzionamento in un livello SCM può essere appropriato se l'altro progetto non è una libreria versione stabile. I progetti in stile vending o mono-repo possono essere molto utili

per gestire le dipendenze interne sviluppate insieme,
quando un progetto esterno non fornisce pacchetti adatti,
quando un progetto esterno cambia troppo rapidamente cosicché sia effettivamente necessario mantenere uno snapshot,
o quando un progetto esterno richiede altre modifiche.

Nella maggior parte degli altri casi l'utilizzo degli strumenti di gestione delle dipendenze disponibili è molto più semplice. C'è un piccolo avvertimento sul fatto che le tue build dipendono ora da sistemi esterni e che lo strumento di gestione delle dipendenze potrebbe non essere particolarmente utile, in modo che finisca per causare più problemi di quanti ne risolva. Ma CMake in particolare - nonostante i suoi numerosi difetti - è piuttosto bravo a evitare l'incompatibilità totale. OTOH puoi sempre creare una semplice shell o script Python che scarica e compila la dipendenza, se la portabilità non è un problema.

Vorrei anche sottolineare che i sotto-repository hanno problemi. Per esempio. un git submodule richiede passaggi aggiuntivi durante il checkout del progetto principale e può avere semantica confusa.