#6415: "sage -t foo.pyx" should not by default dynamically build foo.so
-------------------------+--------------------------------------------------
Reporter: GeorgSWeber | Owner: tbd
Type: defect | Status: new
Priority: major | Milestone: sage-4.1
Component: doctest | Keywords:
Reviewer: | Author:
Merged: |
-------------------------+--------------------------------------------------
Recently (during Sage Days 12 ?!) the doctesting code was changed so that
"sage -t" on a certain class of *.pyx files now is broken.
Especially, they now get not only copied to some temp directory, but it is
attempted to build dynamically the *.so extension out of them, as if they
were all files to be loaded/attached.
This almost certainly must fail, if e.g. you have installed a package
under $SAGE_ROOT/local/lib/python/site-packages/, with Cython extensions,
building which needs certain libraries, additional C sources, special
compiler flags, and so on.
(And where one "imports" the functionality, not loads/attaches it.)
Previously, doctesting was very well suited to this situation, but is no
more.
So the current (Sage 4.0.2) doctesting code should be enhanced in e.g. one
of the following ways:
1) If "dynamically building" of an extension fails, just "try" to import
the functionality as a fallback (in other words: use a prebuilt *.so if
one exists, and you can't build a fresh one)
2) Change to the old behaviour, and additionally try build dynamically an
extension only if it is missing and/or seems to be outdated compared to
the *.pyx file
3) Use the old/new behaviour depending on whether ".../site-packages/..."
is in the path of the *.pyx-file, or not.
At the core of these problems of course is the fact that there is no
standard way to store the build information (not to talk of the "full"
dependency information) for a Cython source file.
The Sage project e.g. invented its own custom-made monolithic
"module_list.py" on the one hand, its custom-made #clib, #cinclude, ...
pragmas on the other hand, but all this does not at all work smoothly
together.
Let alone being usable in Sage-related Cython projects which address a
broader audience, and are thus placed under .../site-packages/.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/6415>
Sage <http://sagemath.org/>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en
-~----------~----~----~----~------~----~------~--~---
