On Wed, Feb 8, 2012 at 16:26, William Stein <wst...@gmail.com> wrote: > On Wed, Feb 8, 2012 at 4:20 PM, Robert Bradshaw > <rober...@math.washington.edu> wrote: >> On Wed, Feb 8, 2012 at 4:00 PM, William Stein <wst...@gmail.com> wrote: >>> On Wed, Feb 8, 2012 at 3:39 PM, Dr. David Kirkby >>> <david.kir...@onetel.net> wrote: >>>> On 02/ 8/12 09:41 AM, Julien Puydt wrote: >>>>> >>>>> Le mardi 7/2/2012, David Kirkby<david.kir...@onetel.net> a écrit : >>>>>> >>>>>> Unfortunately, from a developers point of view, it is not the easiest >>>>>> language to learn, and my experience of many Sage developers would >>>>>> suggest they will not be over keen on studying the details >>>>>> of .autoconf I can't exactly blame them either. >>>>> >>>>> >>>>> If there were : >>>>> (1) some documentation on autoconf in sage ; >>>> >>>> >>>> That sounds like re-inventing the wheel, as others have written >>>> documentation on autoconf. Unless there is anything Sage-specific, I don't >>>> see the need for this. >>>> >>>> >>>>> (2) with already a few things converted to serve as examples ; >>>> >>>> >>>> There are lots of examples on the web, but I still believe a good >>>> understanding is required to write decent scripts for a non-trivial project >>>> like Sage. I don't think someone will get that by looking at others. >>>> >>>> >>>>> Then that would already cover a large proportion of the cases by >>>>> copy-pasting! >>>> >>>> >>>> I don't think its that easy to do it right. >>>> >>>>> Snark on #sagemath >>>>> >>>> >>>> I like the idea, and may be able to offer some help, but I'm aware this is >>>> a >>>> non-trivial project. The rewards would be pretty great though. >>> >>> After following this whole thread, I still have absolutely no idea >>> what this "non-trivial project" even is. What functionality is being >>> proposed to add to the Sage build system? >> >> I'm also curious how the top-level makefile would benefit from a >> (auto)configured, and what the implications would be for installing >> things (such as sage -i ...) when being invoked via this top-level >> make file. I do really like the idea of using (documented and checked) >> flags rather than random environment variables to control how things >> are build globally, as well as, if possible, persisting the decisions >> once ./configure is done running. > > Believe it or not, the environment variables that control how Sage is built > globally are documented (and aren't random): > > http://sagemath.org/doc/installation/source.html#environment-variables
Which I am always bring up to reference, it would be much nicer to have a simple "./configure --help" to list off my options. One thing that it would bring (that I would appreciate), would be the removal of the need to re-export any environmental variables when resuming a build from a different/new session. > > -- William > >> >> - Robert >> >> -- >> 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 > > > > -- > William Stein > Professor of Mathematics > University of Washington > http://wstein.org > > -- > 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 -- Andrew -- 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
