#9914: Remove libraries from extension modules when they are not needed there at
build time
------------------------------+---------------------------------------------
Reporter: leif | Owner: leif
Type: defect | Status: needs_info
Priority: major | Milestone: sage-4.6
Component: build | Keywords: module_list.py PARI ImportError
newforms homspace mwrank upgrade update
Author: Leif Leonhardy | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
------------------------------+---------------------------------------------
Changes (by leif):
* status: needs_work => needs_info
Comment:
Replying to [comment:6 GeorgSWeber]:
> Solution:
>
> Just artificially bump up the version number of the eclib spkg.
> (No real changes are done to its contents --- and often in the past,
even the update of the SPKG.txt was forgotten, but that's another matter,
one should do that always).
>
> As a result, during an update, the eclib spkg *will* be built anew, and
as a consequence, also during "sage -b" the mentioned extensions are
rebuilt. Et voila.
This doesn't work either, see
http://trac.sagemath.org/sage_trac/ticket/9896#comment:16. (Bumping the
patch level is equivalent to doing {{{./sage -f ...}}}.)
> I think there's a very good chance to get the update from Sage-4.5.3 to
Sage-4.6 working, just by artificially bumping up the version numbers of a
handful spkg's (in the sense I described above).
Nevertheless, imagine upgrading MPIR (#8664). Do you want to bump the
version numbers of dozens of packages? Changing {{{sage-spkg}}} to
{{{sage-spkg -f}}} in {{{spkg/standard/deps}}} avoids this, but doesn't
solve all problems we have with (re)building the Sage library.
Robert B. wanted to make Cython smarter such that more of what's manually
provided in {{{module_list.py}}} gets deduced automatically from the
Cython source files (through pragmas), but the new Cython 0.13 doesn't yet
support these enhancements.
So unfortunately we currently have to keep hacking {{{module_list.py}}}
and {{{setup.py}}} to get around subtle dependency issues...
We might as an alternative add {{{depends = [ ... ]}}} to these extension
modules to get them updated when ECLIB gets (I think in general not a bad
idea), but this doesn't really address the PARI issue, i.e. that the
library should IMHO not be listed there.
There are or have been btw. other weird things like {{{libcsage}}} and
{{{libstdc++}}} being linked to each and every module, regardless of the
language or if the module referenced symbols from there at all.
I started cleaning up {{{module_list.py}}} month ago (which is quite
tedious), but then Robert said we'd have a better solution in the near
future...
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9914#comment:7>
Sage <http://www.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.
