William Stein wrote: > On Tue, Oct 13, 2009 at 4:15 PM, Dr. David Kirkby > <david.kir...@onetel.net> wrote: >> Ralf Hemmecke wrote: >>> On 10/13/2009 08:36 PM, David Kirkby wrote: >>>> 2009/10/13 Ralf Hemmecke <r...@hemmecke.de>: >>>>> Would there be interest in the following workflow for installing sage. >>>>> >>>>> a) Get the sage tarball >>>>> b) extract the tarbal to SOMEDIR >>>>> c) cd SOMEDIR >>>>> d) configure (with or without --prefix) >>>>> e) make >>>>> f) make install >>>> I would add >>>> g) make test >>>> I must admit, I would prefer this, as it tends to be more common. >>> Right. >>> >>> > But to write the configure.ac, which generates the Makefile, would be >>>> quite a bit of work to get it right. >>> Just generating the toplevel makefile (and perhaps sage-env) should be >>> easy. But you probably also mean spkg/install and spkg/standard/deps. If >>> these would be the only files (in a first round) that would be doable. >>> Have I forgotten anything? >> I think creating the spkg-installs would not be doable without an effort >> which far exceeds any gainst. >> >>>> Most, if not all of the pre-req-0.4 thing I wrote recently would no >>>> doubt then be moved to this top-level configure script if this was >>>> done. >>> What is pre-req-0.4? >> Sorry, my mistake. It is 'prereq-0.4'. It is code which does the >> preliminary checks of the Sage build. It ensures the build environment >> is sane, using supported tools etc. Such as: >> >> >> * Your version of gcc is not too old or too buggy. >> * You get a warning if using non-GNU compilers. >> * You get a warning on any non-supported platform. >> >> Read more about my changes to it at: >> >> http://sagetrac.org/sage_trac/ticket/7021 >> >> I've noticed a couple of bugs with it, neither of which are too serious >> and neither of which are any worst than the previous behaviour - just >> not as good as I would have liked. >> >> In all honestly, I think any attempt to replace the top level makefile >> with a configure script will be more effort than it is worth. >> > > There is one version of this that I think could be useful. > > (1) ./configure does absolutely *nothing*.
Well doing nothing wont be too helpful. I guess it should at the very least say "please type make". One problem is that when someone looks at the top level, then are going to see both a configure script and a makefile. That might be a bit confusing. Do you type 'configure' or do you type 'make'? Sage will always be different from other packages if there is both a configure script and a makefile. It probably would not be too difficult to have the configure script have some echo statements, so it actually creates the exact same makefile we already have. So when they look, they only see the usual 'configure' script, and no makefile at all. After they type 'configure', they have a makefile, which is not created in the normal way the makefiles are, but just via some echo statements. I must admit, I don't know if autoconf configure supports writing arbitrary stuff into a file. Ultimately, the configure script created by autoconf is just a shell script, so if necessary we could manually do that. But I expect it is possible to write things to a file using standard autoconf macros. > (2) ./configure --help prints some info about building sage, including > influential environment variables That sounds a really good idea. I think it needs a warning though that not all packages respect these environment variable. CC and CXX are ignored by several. > (3) ./configure --prefix=/a/path/somewhere > would create an "install target" file somewhere, which would be > recorded. This would in no way impact the current 'make' procedure. Sounds logical > (4) "make" would work 100% as it does now. Sounds logical > (5) "make install" would do nothing unless the user did step (3) > above, in which case it would install sage in that location. Agreed. > (6) Later ./configure could be improved a little so that one could > pass in some build setting through it (e.g., which fortran to use). > > > 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 To be honest, if we have a configure script at the top level, we might as well move the stuff from prereq into it. It would look a lot more 'normal' if someone see the configure script was checking for the compilers, checking for perl etc. Just do not let the configure script create the makefile in the normal way, but instead create the exact same makefile we have. Dave --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
