Макет каталога для проекта Python с модулями расширения C - PullRequest
5 голосов
/ 20 марта 2010

У нас есть множество проектов в нашей организации, которые являются смешанными Python / C. В настоящее время мы пытаемся стандартизировать макет каталогов для наших проектов и пытаемся придумать удобную схему. Один из спорных моментов - где разместить модули расширения C в дереве.

Мы подбрасываем пару вариантов (относительно корня проекта):

./src/package/subpackage/module.c

или рядом с модулями python в дереве пакетов:

./package/subpackage/module.c

или в каталоге src в подпакете:

./package/subpackage/src/module.c

Одна из причин, по которой они не попадают в каталоги пакетов, может заключаться в том, что это приведет к беспорядку, особенно если есть другие файлы .c и .h, которые сами по себе не являются модулями, но все еще нуждаются в компиляции. Также в «интегрированной» схеме, что вы делаете с заголовками и файлами, которые используются более чем одним модулем? Поместить их в общий каталог верхнего уровня?

Мне было бы интересно узнать, что другие люди используют, или есть ли какие-либо признанные передовые методы для этого.

1 Ответ

1 голос
/ 20 марта 2010

Я думаю, что компоновка стандартной библиотеки Python является разумным примером: под trunk , который в основном является корнем для репозитория SVN (net of branch & c), каталог Modules имеет много файлов .c и .h, в каталоге Lib много файлов .py.

В моих собственных проектах я склонен делить источники аналогичным образом (и на самом деле, если у меня есть Cython или Pyrex, или SWIG и т. Д., Я склонен иметь другие каталоги, но для подразделений), хотя с другими именами каталогов (признаюсь, я не У меня нет единого правила для имен каталогов, и я никогда не слышал о хороших правилах для таких имен).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...