Quand on écrit un projet open-source et utilise Google Code ou GitHub, et que l'on veut utiliser une bibliothèque comme Lua, comment faire?
Étant donné que la bibliothèque n'a pas besoin d'installation avant la compilation.
Réponses:
Je recommande fortement de lire la documentation de Git sur les sous-modules ; il résout ce problème, en supposant que toutes vos sources utilisent Git. Si ce n'est pas le cas, vous pouvez toujours configurer un référentiel git à des fins d'intégration. L'effort est insignifiant et le gain est important.
La dépendance doit-elle être incluse dans le référentiel?
Je pense que les dépendances devraient toujours être incluses dans le référentiel tant que les inclure ne viole aucune condition d'utilisation. Peu de choses sont plus ennuyeuses que d'avoir à trouver manuellement les bonnes versions des bonnes dépendances avant de pouvoir faire une construction. Bien sûr, cela est facile lorsque vous disposez d'outils automatisés pour le faire à votre place, qui peuvent trouver et télécharger la bonne dépendance, mais que se passe-t-il si vous n'êtes pas connecté au Web pour le moment ou si le serveur est en panne ou le projet de la dépendance a été complètement interrompu et mis hors ligne? Incluez toujours les dépendances si possible.
La dépendance doit-elle être générée à partir du même script de génération que le reste du projet, ou à partir d'un script de génération distinct?
À moins qu'il n'y ait une bonne raison de compiler à partir des sources, utilisez des versions précompilées.
Et pourquoi ne pas fournir des options dans le script de construction? Un simple commutateur pour choisir si les dépendances doivent également être compilées ou non. Si l'utilisateur choisit également de compiler les dépendances, il suffit d'appeler ses propres scripts de build à partir du script de build de votre produit. Ainsi, l'utilisateur peut invoquer manuellement les scripts de construction des dépendances ou choisir de créer une version complète de tout. Mais je livrerais les dépendances sous forme de binaires s'il n'y a pas de bonne raison de les compiler à partir des sources. Je pense que dans le monde Open Source, certaines licences vous obligent à distribuer les sources avec votre produit, mais cela ne signifie pas que vous ne pouvez pas les faire précompiler.
En bref: fournissez un ensemble de travail autonome, si possible. Cela fournira le plus de confort à vos utilisateurs.
Cela peut ou non s'appliquer à votre cas d'utilisation, mais ce que nous faisons au travail est d'inclure un dossier "Références" dans chaque branche. Nous plaçons ici des DLL tierces. Cela provoque beaucoup de duplication de binaires relativement immuables dans le contrôle de code source, mais le stockage est bon marché et à tout moment chaque branche et balise a exactement les dépendances (et la version!) Qu'elle attend.
Nous précompilons les dépendances nous-mêmes et déplaçons les binaires compilés dans ce dossier. Notre propre bibliothèque partagée en interne est également traitée de cette façon. De cette façon, la même technique fonctionne pour les bibliothèques propriétaires précompilées, les bibliothèques open source et les bibliothèques internes.
En ce qui concerne la réponse à votre question maintenant que je l'ai relue, faites la même chose et mentionnez simplement que votre projet utilise une version 1.3.5 précompilée de Lua.
La dépendance doit-elle être incluse dans le référentiel?
Il peut être référencé dans le référentiel (par n'importe quelle méthode utilisable pour SCM), si cette dépendance fait partie intégrante du produit (source-dépendance), pas la dépendance binaire, qui peut être résolue séparément
La dépendance doit-elle être générée à partir du même script de génération que le reste du projet, ou à partir d'un script de génération distinct?
Peu importe du tout. Vous pouvez préférer n'importe quelle méthode, selon vos besoins (rapidité / transparence / gérabilité / etc)
Étant une boutique Eclipse, nous venons de commencer à utiliser Buckminster pour gérer notre processus de construction / assemblage / déploiement.
Notre première étape a été de retirer toutes nos bibliothèques dépendantes existantes et de laisser buckminster se charger de matérialiser les bonnes. Cela permet un déploiement beaucoup plus rapide et plus petit.
La prochaine étape consistera à déplacer notre svnréférentiel monolithique vers une série de gitréférentiels modulaires .
Je ne sais pas comment Buckminster s'intégrerait bien avec les gitsous-modules (ou les sous-dépôts mercuriels d'ailleurs), mais il est agréable que Buckminster soit agnostique en ce qui concerne le VCS utilisé pour un composant donné.