Verzeichnis-Layout für ein Python-Projekt mit C-Erweiterungsmodulen

Question

Wir haben zahlreiche Projekte in unserer Organisation, die gemischt Python/C sind. Derzeit versuchen wir, ein Verzeichnislayout für unsere Projekte zu standardisieren und versuchen, ein komfortables Schema zu finden. Ein Streitpunkt ist, wo C-Erweiterungsmodule in den Baum eingefügt werden sollen.

Wir werfen ein paar Optionen um (relative Wurzel zu projizieren):

./src/package/subpackage/module.c 

oder neben den Python-Modulen im Paketbaum:

./package/subpackage/module.c 

oder in einem src Verzeichnis in das Unterpaket:

./package/subpackage/src/module.c 

Ein Grund dafür, sie aus dem Paketdirektor herauszuhalten Dies kann sein, weil es zu Unordnung führt, besonders wenn es andere .c und .h Dateien gibt, die selbst keine Module sind, aber trotzdem kompiliert werden müssen. Was machen Sie im "integrierten" Schema auch mit Headern und Dateien, die von mehr als einem Modul verwendet werden? Legen Sie sie in ein gemeinsames Verzeichnis der obersten Ebene?

Ich wäre interessiert zu wissen, was andere Leute verwenden, oder wenn es Best Practices dafür gibt.

Answer 1

Ich denke, das Layout der Python-Standardbibliothek ist ein vernünftiges Beispiel: unter trunk, die für den SVN Repo (nach Abzug der Zweige & c), das Modules Verzeichnis viel .c und .h Dateien hat im Grunde die Wurzel, das Verzeichnis Lib viele .py Dateien.

In meinen eigenen Projekten tendiere ich dazu, Quellen auf ähnliche Weise aufzuteilen (und tatsächlich, wenn ich Cython- oder Pyrex-Einsen oder SWIG usw. habe, tendiere ich dazu, andere Verzeichnisse zur Unterteilung zu haben), allerdings mit anderen Verzeichnisnamen (ich gestehe, ich habe keine konsistente Regel für die Verzeichnisnamen selbst, noch habe ich jemals von guten Richtlinien für solche Namen gehört).