et on fait les ajustements nécessaires sur la partie build
C'est justement ça qu'on a pas envie de faire (voir ci-dessous)
Pourquoi pas monorepo ?
Version courte: pour des raisons historiques, d'intégration, et aussi un peu philosophiques.
Version longue:
Raison historique: Avant, on avait nos dépendances C++ (les fichiers .so, .a, .dylib et tous leur headers) pré-compilées dans un gros dépôt git. Du coup comme le dépôt était gros toutes les opérations (git status, par exemple) prenait du temps. Du coup c'était pratique d'avoir un deuxième dépôts avec juste nos sources à nous. (Depuis on est passé à conan
Intégration: nous utilisons gitlab-ci. Si tu as un seul dépôt qui mélange C++ et Javascript par exemple, il va falloir regarder quelle portion du code a été changée. (Lancer le build et les tests en C++ est long, et lancer tous les linters et les analyseurs statiques Javascript est long aussi: tu as envie de lancer uniquement ce qui concerne ce qui a changé. Du coup si t'es un peu obligé de hacker gitlab-ci pour rajouter ce genre de fonctionnalité.
La dernière raison est plus subtile. L'idée c'est qu'on veut avoir un système qui tienne la route même avec beaucoup de projets et beaucoup de développeurs. La solution du mono-repo fonctionne mais demande du travail spécifique (les problème d'intégration continue et de performance des gestionnaires de code ne sont que des exemples parmi d'autres). Du coup la solution que nous choisissons se rapproche des modes de développement open-source (pensez à Gnome ou KDE et leur myriade de projets séparés), ce qui nous permet à la fois de bénéficier des outils existants, mais aussi de partager nos problèmes (et nos solutions) avec le reste de la communauté open source.
[^] # Re: je ne suis pas sûr d'avoir saisi l'intérêt de l'outil
Posté par Dimitri Merejkowsky (site web personnel) . En réponse à la dépêche tsrc — un gestionnaire de dépôts git. Évalué à 8.
C'est justement ça qu'on a pas envie de faire (voir ci-dessous)
Version courte: pour des raisons historiques, d'intégration, et aussi un peu philosophiques.
Version longue:
Raison historique: Avant, on avait nos dépendances C++ (les fichiers
.so,.a,.dylibet tous leur headers) pré-compilées dans un gros dépôt git. Du coup comme le dépôt était gros toutes les opérations (git status, par exemple) prenait du temps. Du coup c'était pratique d'avoir un deuxième dépôts avec juste nos sources à nous. (Depuis on est passé à conanIntégration: nous utilisons
gitlab-ci. Si tu as un seul dépôt qui mélange C++ et Javascript par exemple, il va falloir regarder quelle portion du code a été changée. (Lancer le build et les tests en C++ est long, et lancer tous les linters et les analyseurs statiques Javascript est long aussi: tu as envie de lancer uniquement ce qui concerne ce qui a changé. Du coup si t'es un peu obligé de hacker gitlab-ci pour rajouter ce genre de fonctionnalité.La dernière raison est plus subtile. L'idée c'est qu'on veut avoir un système qui tienne la route même avec beaucoup de projets et beaucoup de développeurs. La solution du mono-repo fonctionne mais demande du travail spécifique (les problème d'intégration continue et de performance des gestionnaires de code ne sont que des exemples parmi d'autres). Du coup la solution que nous choisissons se rapproche des modes de développement open-source (pensez à Gnome ou KDE et leur myriade de projets séparés), ce qui nous permet à la fois de bénéficier des outils existants, mais aussi de partager nos problèmes (et nos solutions) avec le reste de la communauté open source.