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*.
(2) ./configure --help prints some info about building sage, including
influential environment variables
(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.
(4) "make" would work 100% as it does now.
(5) "make install" would do nothing unless the user did step (3)
above, in which case it would install sage in that location.
(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
will install that program in /usr/local/. When that expectation is
not met, I get really annoyed. I really don't care one bit *how*
"./configure" (or make, etc.) is implemented -- just that they have
the semantics I expect.
If it's a Python program, then I expect that:
python setup.py install
will install the program in site-packages/ for that install of python.
If not, I get really annoyed.
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, or even using autoconf to implement ./configure. 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.
-- William
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
