> My perspective on Ralf's proposal is not to rewrite anything we > currently do, but to make it so building Sage feels "standard". I.e., > when I download some random tarball off the web, if it is a C/C++ > program I 100% expect that: > > ./configure --prefix=/usr/local/ # say > make > make install > > will install that program in /usr/local/.
You got me. ;-) > So, from this perspective, Sage itself is annoying. ;-) > Let me emphasize again that from this perspective the question > is *NOT* about moving code in the current build system into some > uber ./configure script, Right. Usually if a program contains sub-packages, the configure scripts of the sub-packages are called. (Actually, I am not a total autoconf expert, but I'd say, subpackages will be configured when they are due. (However, they should somehow honor the options given at the top-level configure. Of course, how to honor them depends a lot of the overall infrastructure of how the subprograms work inside sage.) > or even using autoconf to implement ./configure. Well, to be honest, I had a tendency to using autoconf. ;-) > The idea I > think Ralf is proposing is simply that the process for getting and > installing Sage involve exactly the same commands as with 99% of other > build-from-source software, with the same semantics (meaning). > Ralf, am I right, or am I missing your point? If I'm missing your > point, I would like to argue that my perspective above is in fact the > right one anyways. No, you are right. However, I hesitate to do anything, because from what I know by now, sage *is* different. Sage comes with (at least some) sources to enable to user to change Sage. In some sense that is good and disireable, but it is also against a "make install" step. Why? If you say "configure && make" followed by "sudo make install" then Sage would live in /usr/local and nobody could directly modify Sage because of permissions. So such an installation would be a site-wide installation pretty similar to an installation of other CAS. So one should install sage in ones HOME directory. Maybe that is a waste of diskspace. Unfortunately, I don't yet have a complete picture of how the components of sage work together and I don't want to change too much. There were certainly reasons that sage is as it is. Also, different from other systems, there is python code, interpreted. When changed, it can take immediate effect without the need of another "make && make install". I guess that is probably very much desireable for people. So having another infrastructure (like putting the sources into $HOME/sage-source and the installation under $HOME/sage-install) is probably not in the spirit of sage. Hmm, let me come up with a suggestion for this problem. One installs sage under /usr/local. Every user hase a .sage-config file which tells the system a directory [sources] $HOME/somewhere where Sage can find its .py files. Then, if the system wants to load a .py file, it first looks into the user's directory. I've no idea whether that would be manageable/reasonable. I'm just thinking loudly about another way of Sage's infrastructure. I've certainly forgotton all the people that work under $SAGE_ROOT/devel. And I have no idea about the Cython stuff, so forgive me. Ralf --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
