On Thu, Jul 3, 2014 at 7:21 AM, John H Palmieri <[email protected]> wrote: > > > On Thursday, July 3, 2014 3:59:45 AM UTC-7, Nicolas M. Thiéry wrote: >> >> Dear Sage developers, >> >> I recently noticed some preliminary work in src/setup.py toward >> compiling the Sage library in place, instead of putting the produced >> .so and copies of the .py files in src/build. >> >> Compiling in place means saving 15s of `sage -b` each time I just >> modify Python code, and I do that all the time; so we are speaking of >> dozen of minutes per day. So I have been dreaming of it for >> years. Besides, it would also remove one of the regular source of >> confusions for our new contributors. >> >> So I explored this further, and with very minimal further changes >> (diff attached; I'll push a branch to trac once I have a good enough >> internet connection), this apparently seems to work smoothly: I >> haven't yet run all tests, but Sage starts, the documentation >> compiles, etc. >> >> I can't wait until I can use this for real Sage development. But for >> this, I basically need to get this feature into Sage. It would be >> adventurous to enable this feature by default for all users at this >> point. On the other hand, we should allow the adventurous of us to use >> this extensively to chase out the bugs. >> >> What would be the right approach to make this feature configurable >> when one compiles Sage for the first time? Using just an environment >> variable set by the user is not good, since a given user might have >> Sage installations configured differently. Some piece of information >> must be stored somewhere at configuration time. >> >> Btw: do we have an open ticket for this? > > > > The ticket > > http://trac.sagemath.org/ticket/12659 > > has the right title, anyway.
Yes, that's from when Mike Hansen solved this same problem a few years ago... but then both of us got distracted and somehow it didn't end up in Sage, despite getting a positive review and then un-getting that (getting this to work right is subtle). There are many major advantages to building in place beyond the ones that Nicolas mentioned and Volker wasn't convinced about. 1. Building in place saves disk space. It saves a *lot* of disk space, since we don't end up with two copies of every .so (and py/pyc). 2. Building in place reduces *confusion*. I can't tell you how many times I've seen people loose work, get confused, etc., because they type foo??, see the filename, edit that file (in local/lib/python/site-packages!), only to find it gets overwritten later. I remember that trying to alert people to this confusing aspect of Sage development was one of Robert Miller's pet peeves, since he saw it soooo often. Building in place completely removes this point of confusion. Instead of foo being defined in two files, it is defined in only one. Similar remarks for .so files -- instead of being in build and site-packages, they are right next to the .pyx files. Personally, I would much prefer if build in place were the only option in sage-6.4, rather than having some intermediate period with an environment variable. Volker (and everybody) are so good at testing and ensuring stability of releases, that I think this can be done without introducing a build flag. But I'm not doing the actual work on this, and the above is just my opinion. William -- William Stein Professor of Mathematics University of Washington http://wstein.org -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
