Stefan Behnel wrote:
> That does not answer my question about a use case. You mentioned different
things so
> far, one being source code layout versus shipping in packages, one being
users moving
> modules around as they see fit. I understand that some people require the
first for
> legacy reasons ("we always kept our sources in that one directory!"). I
don't see a
> reason for the latter.
Here is our module directory structure:
module/
src/
*.c, *.h [common source code]
standalone/
*.c [contain at least main() and the command line parser]
Makefile
build/
Linux/
[intermediate files + binary executable]
Win32/
[intermediate files + binary executable]
test/
[test files as shell scripts]
python/
[needed wrapper files]
Makefile
build/
Linux/
[intermediate files + python wrapper]
Win32/
[intermediate files + python wrapper]
test/
[test files as Python scripts]
[other platforms]
test/
[test files as Python scripts]
Makefiles build everything in the corresponding build/<platform>/
test/ within platform directories are dedicated to their platform. They get
access to the "executable" by ../build/<platform>/
Concerning python tests, they start with:
import sys, os, platform
sys.path.append(os.path.join("..", "build",
platform.system().replace("Windows", "Win32")))
The global test/ contains test that validate everything between releases and
platforms.
They don't rely on ../<platform>/build/<platform> directories, but have
their own build structure, because they have to download previous releases
from the datatabase and build them.
Note that, when everything is validated, python wrappers are put into
packages within site-packages for final users. OK, I previously mentionned
that users may move them, but in fact they don't, it was just to avoid
having to detail the complex test suite structure. Sorry if this finally
disturbed you.
Anyway, all those mechanisms worked well until I decided to use Cython in
replacement of SWIG.
This is because the test suites don't care of the destination package. They
just set the path to the built modules (through sys.path for Python) and
load/launch them (import for Python).
For sure the structure could be modified to support a package hierarchy, and
I asked for it, but to summarize other developpers answer I got: "you want
to use Cython, why not, but you have to ensure this is backward compatible.
If not, stop using Cython."
This is why I'm patching the generated C code for the moment.
Cheers,
Stephane
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
