On 06/21/10 07:30 PM, Robert Bradshaw wrote:
On Jun 15, 2010, at 12:50 AM, David Kirkby wrote:
On 15 June 2010 02:41, Pablo De Napoli <pden...@gmail.com> wrote:
I really think that spliting users into "developers" and "non
developers" is very much against the spirit of open source
I'm not sure if its against the spirit of open-source. Many of us use
packages we do not develop - OpenOffice is one example for me.
And OpenOffice is not a very healthy looking project... Firefox is
another good example of users >> developers.
I suspect the very nature of Firefox and OpenOffice means many users are not
very technical, so are less likely to be developers. Of course there are
exceptions, but I would suspect it is generally more true than with Sage
Any barrier of entrance to development is against that.
+1 It is against the spirit of Sage to widen this gap.
I think what is often overlooked is that just because you are a good
mathematician and can use Sage, it does not make you a good developer. If Sage
is ever to become a viable alternative to the 4 M's for a lot of people, then it
needs software engineering skills.
I'm not proposing we make a barrier. What I propose is that we warn
uses that setting these variables does not work correctly, but allow
them to do so if they wish. At the minute, there is no warning if one
set CC or CXX, despite the fact they are not fully supported in Sage.
I'm +1 to a warning for having CC and CXX set, there's a distinction
between developing Sage and trying to build it in as-yet unsupported
(and known broken) ways and platforms.
Rather than having a plethora of environment variables to set, perhaps
we could have a different make target (e.g. make porting or make
experimental) that would run the prereq script in interactive mode (e.g.
"CC is unsupported and set, continue anyways? [y/N]")
I've never come an autoconf script (which is what prereq is), that is
interactive. Even if it could be done, I think it defeats the whole point about
autoconf. I'd personally find that annoying. Then you would have to start using
programs like 'expect' to perform non-interactive builds.
Whilst one will have to set certain environment variables, these can at least be
added to a .profile/.bashrc or whatever you want.
I have "SAGE_PORT=yes" as an environment variable, so its always seen.
Also, the environment variables are self-documenting, in that if you need one,
it tells you what to type.
Moreover, I think that the idea of that all the environment has to be
controlled when building sage and therefore all the dependencies
should be included has some serious drawbacks, like making difficult
the creation of packages for different linux distributions
(see how difficult would be to update the current debian package to
the current sage version)
and this goal would be important for attracting more non-technical
users to sagre.
I agree, but I also see Williams point that having to require people
to have a large number of different packages, modified in some way,
would be very difficult.
+1. Forcing the user (or each of several linux distributions) to manage
the dependancies would not make things easier IMHO.
-Robert
It's just a shame that the present system of using Sage puts off many Linux
distributions. But I don't claim to know the answer - it's just an observation.
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
