Most of sage-location can safely be deleted. I did it once and nobody reviewed it so I'm not that motivated to fix the merge conflicts that since have accrued.
http://trac.sagemath.org/ticket/19908 On Friday, March 18, 2016 at 5:00:54 PM UTC+1, David Roe wrote: > > > On Fri, Mar 18, 2016 at 11:14 AM, William Stein <wst...@gmail.com > <javascript:>> wrote: > >> On Fri, Mar 18, 2016 at 8:11 AM, Volker Braun <vbrau...@gmail.com >> <javascript:>> wrote: >> > On Friday, March 18, 2016 at 4:06:04 PM UTC+1, William wrote: >> >> >> >> > Also, your use case is a bit weird; Parallel installations on the >> same >> >> > server? >> >> >> >> It's David's use case for Sage Days 71. It seems to me like a >> >> reasonable use case for development. >> > >> > >> > In fact, in that odd case why not compile once and then just create >> ordinary >> > copies? The copies will have dangling rpaths to the original, but as >> long as >> > you don't change the original you'll be fine. >> >> David, my understanding is that is exactly what you tried to do, then >> wondered why it didn't work: "So I tried building a copy from source >> and then copying it five times. Unfortunately, the relocation script >> is run at the end of the installation, making it uncopyable. This is >> despite the fact that I refrained from starting Sage after building >> it." >> > > Yeah, that's exactly what I tried. The original was still in place, but > Sage failed to start since it detected that it had been moved. > > I understand that there were reasons for the recent change, and I'm not > arguing that we should return to rpaths. I have two objectives in this > thread: > > * to learn (and record for others) if there's something different I can do > during the build process to make a Sage installation copyable in the case > where I'm building from source and know in advance that I want to be able > to "cp -a SAGE_OLD_LOCATION SAGE_NEW_LOCATION." William suggested adding > sys.exit(0) at the top of the relocation script (and remove it after > copying). Any other ideas? > * to encourage people to make relocation better. I've never been > interested in working on Sage's build system, so I'm not going to be > submitting a pull request on this issue. I'm sorry if my original e-mail > came across as condemning the work others had done on the changes to rpaths > -- that wasn't my intention. But I remember someone saying that it might > be possible to allow the relocation script to be run multiple times > (without having to rebuild all cython files and documentation). That's > something I would like. > > As a final question, I've been avoiding binary installations for years now > because, at some point, it was difficult to modify them. I don't recall if > the issue was that you had to rebuild the whole Sage library, or some other > problem. If I want to develop Sage, starting from a binary, are there any > issues I should be aware of? > David > > William >> >> >> -- >> William (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 sage-devel+...@googlegroups.com <javascript:>. >> To post to this group, send email to sage-...@googlegroups.com >> <javascript:>. >> Visit this group at https://groups.google.com/group/sage-devel. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
