On 04/19/2015 11:42 PM, ggrafendorfer wrote: > On Sunday, April 19, 2015 at 8:28:49 PM UTC+2, leif wrote: > > On 04/19/2015 06:42 PM, John Cremona wrote: > > Do you have a reason for having SAGE_ROOT set at all? I don't. > > That's exactly the purpose of a *user-set* SAGE_ROOT: To run a Sage > installation *somewhere else* in the filesystem hierarchy. > > It's probably a bit surprising that that even works with (e.g.) > './sage', but in principle intentional. > > > -leif > > > Seems like we have a different understanding of the proper use of > environment variables. > If I type > > sage-6.6$ make ptestlong > > then I expect that the test is done with the "new" sage-6.6, which can > be found in the same directory as the makefile, no matter if SAGE_ROOT > is set (to whatever) or not.
Agreed, /that/ "use case" is rather unintended. We'd have to check whether SAGE_ROOT is set and points somewhere else in the Makefile to avoid such potentially surprising behavior. (It's less obvious that 'sage' is called from the Makefile and hence SAGE_ROOT is used / relevant there at all.) But e.g. './sage -t ...' (or 'sage -t ...') should IMHO still "respect" SAGE_ROOT if it is set (since that's its purpose). I wouldn't mind if you opened a ticket for disallowing / disabling SAGE_ROOT in case the current working directory happens to contain a different Sage installation though (which also covers the 'make' case). Presumably not as easy to implement as one might think in the first place. -leif -- 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.
