On Fri, Jan 7, 2011 at 6:53 AM, emil <emil.widm...@gmail.com> wrote: > just take the mentioned directories as examples: > Intuitively I would assume /devel/sage-main/sage contains the "real" > binaries > everything in /devel/sage-main/build is necessary for development. > Right or wrong?
This is wrong, as you might discover if you delete that directory, then try to use Sage. There is a symlink from SAGE_ROOT/local/lib/site-packages/sage to SAGE_ROOT/devel/sage/build/sage The best solution to the problem we're discussing in the context of SAGE_ROOT/devel/sage would be to change the Sage library to build all .so's in place, so that the SAGE_ROOT/devel/sage/build would in fact be redundant, and there would only ever be exactly one copy of each file (or .so) in SAGE_ROOT/devel/sage. This is what happens with "python setup.py develop" or "setup.py build_ext --inplace <list of extension names>", when using setuptools instead of distutils. For example, with the Sage Notebook and PSAGE (http://code.google.com/p/purplesage/), which both use setuptools, we do all of our work this way. Another plus to this change is that if foo is a function and you type: sage: foo?? you'll see the actual location of the file you should edit to modify foo, rather than some highly misleading file in SAGE_ROOT/local (which is a major source of confusion at first). That said, it could be significant and painfully disruptive work for somebody to change the core Sage library to work this way. I hope it happens at some point. Confusion will be reduced overall, as will disk space usage. William -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
