Disposition du répertoire pour un projet Python avec des modules d'extension C

Question

Nous avons de nombreux projets dans notre organisation qui sont mixtes Python/C. Actuellement, nous essayons de standardiser la mise en page d'un répertoire pour nos projets et essayons de trouver un schéma pratique. Un point de contention est où placer les modules d'extension C dans l'arborescence.

Nous jeter autour de deux options (par rapport au projet racine):

./src/package/subpackage/module.c 

ou à côté des modules Python dans l'arborescence du package:

./package/subpackage/module.c 

ou dans un répertoire src dans le sous-paquet:

./package/subpackage/src/module.c 

Une raison pour les garder hors du directeur de paquet Cela peut être dû au fait que cela entraînera un encombrement, en particulier s'il existe d'autres fichiers .c et .h qui ne sont pas eux-mêmes des modules mais qui doivent encore être compilés. Dans le schéma "intégré", que faites-vous des en-têtes et des fichiers utilisés par plusieurs modules? Mettez-les dans un répertoire commun de premier niveau?

Je serais intéressé de savoir ce que d'autres personnes utilisent ou s'il existe des pratiques exemplaires établies à cet égard.

Answer 1

Je pense que la mise en page de la bibliothèque standard Python est un exemple raisonnable: sous trunk, qui est essentiellement la racine pour le repo SVN (net des branches & c), le répertoire Modules a beaucoup de .c et .h fichiers, le Lib répertoire beaucoup de fichiers .py. Dans mes propres projets, j'ai tendance à diviser les sources de la même façon (et en fait, si j'ai Cython ou Pyrex, ou SWIG etc, j'ai tendance à avoir d'autres répertoires pour la subdivision), mais avec des noms de répertoires différents (j'avoue Je n'ai pas de règle cohérente pour les noms de répertoires eux-mêmes, et je n'ai jamais entendu parler de bonnes directives pour de tels noms).