Mise en page du répertoire source de langage mixte

Question

Nous exécutons un grand projet avec plusieurs langages différents: Java, Python, PHP, SQL et Perl. Jusqu'à présent, les gens travaillaient dans leurs propres dépôts privés, mais nous voulons maintenant fusionner l'ensemble du projet dans un seul référentiel. La question qui se pose maintenant est la suivante: à quoi devrait ressembler la structure du répertoire? Devrions-nous avoir des répertoires séparés pour chaque langue, ou devrions-nous le séparer par composant/projet? Dans quelle mesure python/perl/java gère-t-il une mise en page de répertoire commune?

Answer 1

Mon expérience indique que ce genre de mise en page est mieux.

mylib/ 
    src/ 
     java/ 
     python/ 
     perl/ 
     .../ 
    bin/ 
     java/ 
     python/ 
     perl/ 
    stage/ 
    dist/ 

src est source, et est la seule chose vérifiée dans

bin est où « compilation » se produit au cours de la construction et ne le réintègre pas.

stage est l'endroit où vous copiez les choses lors de la construction afin de les préparer pour l'emballage

dist est où vous placez les artefacts de construction

Je place le module/composant/bibliothèque en haut de la hiérarchie, car je construis chaque module séparément, et utilise un gestionnaire de dépendances pour les combiner si nécessaire.

Bien entendu, les conventions de dénomination varient. Mais j'ai trouvé cela pour fonctionner de manière plutôt satisfaisante.

Answer 2

Je pense que la meilleure chose à faire serait de faire en sorte que vos différents modules ne dépendent pas d'être dans le même répertoire (c'est-à-dire séparés par composant). Beaucoup de gens semblent avoir peur de cette idée, mais un bon ensemble de scripts de construction devrait être capable d'automatiser toute douleur.

L'objectif final serait de faciliter l'installation de l'infrastructure, puis de travailler très facilement sur un seul composant une fois l'environnement configuré.

(Il est important de noter que je viens des mondes Perl et CL, où nous installons des "modules" dans un emplacement global, comme ~/perl ou ~/.sbcl, plutôt que d'inclure chaque module avec chaque projet, comme Ce serait un problème de maintenance, mais ça ne finit pas par être le cas ... Avec un script qui met à jour régulièrement chaque module de votre dépôt git (ou CPAN), c'est vraiment la meilleure solution.)

Edit: une chose:

projets ont toujours des dépendances externes. Mes projets nécessitent Postgres et une installation Linux fonctionnelle. Il serait fou de combiner ceci avec le code de l'application dans le contrôle de version - mais un script pour tout installer sur un nouveau poste de travail est très utile. Je suppose que ce que j'essaie de dire, peut-être de façon indirecte, c'est que je ne pense pas que vous devriez traiter vos modules internes différemment des modules externes.