Re: [sage-devel] Should we block the use of CC and CXX except for developers?
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 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
Re: [sage-devel] Should we block the use of CC and CXX except for developers?
On Monday, June 21, 2010, Robert Bradshaw wrote: > On Jun 15, 2010, at 12:50 AM, David Kirkby wrote: > > > On 15 June 2010 02:41, Pablo De Napoli 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. > > > Any barrier of entrance to development is against that. > > > +1 It is against the spirit of Sage to widen this gap. > > > 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 am -1 on anything interactive in any sage build scripts. It makes it a major pain to optimize things and make sure that a build is reproducible. > 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 > > -- > 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
Re: [sage-devel] Should we block the use of CC and CXX except for developers?
On Jun 15, 2010, at 12:50 AM, David Kirkby wrote: On 15 June 2010 02:41, Pablo De Napoli 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. Any barrier of entrance to development is against that. +1 It is against the spirit of Sage to widen this gap. 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]") 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 -- 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
Re: [sage-devel] Should we block the use of CC and CXX except for developers?
On 15 June 2010 02:41, Pablo De Napoli 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. > Any barrier of entrance to development is against that. 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. > 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. 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
Re: [sage-devel] Should we block the use of CC and CXX except for developers?
I really think that spliting users into "developers" and "non developers" is very much against the spirit of open source Any barrier of entrance to development is against that. 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. On Mon, Jun 14, 2010 at 7:49 AM, Dr. David Kirkby wrote: > The recent thread: > > "Error building Sage 4.4.3 under vanilla Debian lenny amd64: Error while > installing flint" > > http://groups.google.com/group/sage-devel/browse_thread/thread/54531b50412b9882/2f45257c5e56ab00?lnk=gst&q=Error+building+Sage+4.4.3+under+vanilla+Debian+lenny+amd64%3A+Error+while+installing+flint#2f45257c5e56ab00 > > > is an example of where someone had a broken installation of Debian > (different versions of gcc and g++), so got an error from the 'prereq' > script, which I altered some time ago to detect different versions and exit. > > The poster then went on to try to get CC and/or CXX in order that he got the > same (older) versions of both. > > Such a plan will never work in Sage, as numerous bits of code make direct > calls to "gcc" or "g++" and ignore the environment variables. So any attempt > to do this results on C compiler being used to build one bit of Sage, and > another to build another bit of Sage. That seems a recipe for disaster. > > Hence I'd propose that any attempt to set CC, CXX, FC, or F77 caused the > build to exit with a warning. Then allow an environment variable like > > SAGE_ALLOW_SETTING_OF_COMPILERS > > (better name?) > > that will allow someone to do this, if they really want to. > > Not letting people set CC or similar seems a bit dumb, as it is very useful > for some sort of debugging, or porting to Sun Studio. But it is pretty > dangerous for a typical user to do, as it will never work as they would > expect. > > The same is true really of CP, CHMOD and several other variables. They work > in some parts of Sage, and not in others. > > 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 > -- 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
Re: [sage-devel] Should we block the use of CC and CXX except for developers?
On Mon, Jun 14, 2010 at 11:05 AM, Dr. David Kirkby wrote: > On 06/14/10 06:39 PM, William Stein wrote: > OK, we will agree to differ. I can't see what harm issuing a warning does - > especially for novice users. > > In contrast, deepening on your point of view, logging data with fake files > can be either a blessing or a nuisance. > > I think in the short term, the main benefit would be to stop users setting > these variables. Getting Sage to build with a non-GNU compiler is not going > to be easy, and certainly wont be done in the short term. Getting it to > build with gcc on OpenSolaris, FreeBSD and Cygwin seems to present more than > its fair share of problems. Alright, I'm personally OK with your proposal to add the warning/error you suggested earlier when certain environment variables are set. Make sure it includes the message about how to disable it. -- William -- 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
Re: [sage-devel] Should we block the use of CC and CXX except for developers?
On 06/14/10 06:39 PM, William Stein wrote: On Mon, Jun 14, 2010 at 9:11 AM, Dr. David Kirkby wrote: On 06/14/10 04:28 PM, William Stein wrote: On Mon, Jun 14, 2010 at 3:49 AM, Dr. David Kirkby Hence I'd propose that any attempt to set CC, CXX, FC, or F77 caused the build to exit with a warning. Then allow an environment variable like SAGE_ALLOW_SETTING_OF_COMPILERS (better name?) that will allow someone to do this, if they really want to. The same is true really of CP, CHMOD and several other variables. They work in some parts of Sage, and not in others. Dave Another possibility might be that if the Sage build system starts and the environment variable CC is defined, then a command "gcc" that runs whatever is specified in CC is created and put first in the path. Then: (1) any build scripts that still annoying look for gcc will instead find this fake gcc wrapper and use it, hence calling CC. (2) We can also make it so this fake gcc wrapper logs whenever it is called, and hence easily nail down which packages are offendors. The same can be done with all the other variables you mentioned. -- William I don't like the fake gcc idea myself. Currently when the fake gcc is run, it obscures what flags are being passed to the compiler - the same with the sage_fortran. We already have one fake gcc, so then we need another one which logs data. I'm unaware of this current fake gcc. Where is it? Who added it? What does it do? Numpy's spkg-install has this. # numpy's distutils is buggy and runs a conftest without # taking CFLAGS into account. With 64 bit OSX this results # in *boom* if [ `uname` = "Darwin" -a "$SAGE64" = "yes" ]; then echo "64 bit MacIntel: copying fake gcc" rm $SAGE_LOCAL/bin/gcc cp gcc_fake $SAGE_LOCAL/bin/gcc chmod 755 $SAGE_LOCAL/bin/gcc fi I'm not sure what creates the fake_gcc in the first place though. That's not working on OpenSolaris. Jaap has tried to modify it, but the mod does not work for me - see http://trac.sagemath.org/sage_trac/ticket/8086 Thanks for letting me know about it. Sorry I can't be more helpful. I don't know what actually creates this. Personally I don't like fake files like this. As I indicate in that trac ticket, it caused me to reboot my machine! It's clear you won't implement a fake gcc/g++, etc. that would make it much easier to track down the problems with components calling GCC when they don't, so I won't try to convince you that this is the best thing to do. OK, we will agree to differ. I can't see what harm issuing a warning does - especially for novice users. In contrast, deepening on your point of view, logging data with fake files can be either a blessing or a nuisance. I think in the short term, the main benefit would be to stop users setting these variables. Getting Sage to build with a non-GNU compiler is not going to be easy, and certainly wont be done in the short term. Getting it to build with gcc on OpenSolaris, FreeBSD and Cygwin seems to present more than its fair share of problems. -- William 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
Re: [sage-devel] Should we block the use of CC and CXX except for developers?
On Mon, Jun 14, 2010 at 9:11 AM, Dr. David Kirkby wrote: > On 06/14/10 04:28 PM, William Stein wrote: >> >> On Mon, Jun 14, 2010 at 3:49 AM, Dr. David Kirkby > >>> Hence I'd propose that any attempt to set CC, CXX, FC, or F77 caused the >>> build to exit with a warning. Then allow an environment variable like >>> >>> SAGE_ALLOW_SETTING_OF_COMPILERS >>> >>> (better name?) >>> >>> that will allow someone to do this, if they really want to. > > The same is true really of CP, CHMOD and several other variables. They work >>> >>> in some parts of Sage, and not in others. >>> >>> Dave >> >> Another possibility might be that if the Sage build system starts and >> the environment variable >> CC is defined, then a command "gcc" that runs whatever is specified in >> CC is created and >> put first in the path. Then: >> >> (1) any build scripts that still annoying look for gcc will instead >> find this fake gcc wrapper and use it, hence calling CC. >> >> (2) We can also make it so this fake gcc wrapper logs whenever it >> is called, and hence easily nail down which packages are offendors. >> >> The same can be done with all the other variables you mentioned. >> >> -- William > > I don't like the fake gcc idea myself. Currently when the fake gcc is run, > it obscures what flags are being passed to the compiler - the same with the > sage_fortran. > > We already have one fake gcc, so then we need another one which logs data. I'm unaware of this current fake gcc. Where is it? Who added it? What does it do? Thanks for letting me know about it. It's clear you won't implement a fake gcc/g++, etc. that would make it much easier to track down the problems with components calling GCC when they don't, so I won't try to convince you that this is the best thing to do. -- William > IMHO, a simple warning is better. That leaves any messing around with logs > in the hands of the developer who is trying to sort out the problems with > the variables. He might prefer to abort at that point, rather than log data > data. If you tried to link object files created from C++ code from the Sun > and GNU compilers, it would certainly end in disaster, to aborting is > probably safest. > > BTW, do we really need a sage_fortran any more? I believe at one point the > reason was there was the possibility of the compiler being g95 or gfortran, > but I believe that is dropped now, and only gfortran will be used. So why > not call gfortran directly? > > 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 > -- 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
Re: [sage-devel] Should we block the use of CC and CXX except for developers?
On 06/14/10 04:28 PM, William Stein wrote: On Mon, Jun 14, 2010 at 3:49 AM, Dr. David Kirkby Hence I'd propose that any attempt to set CC, CXX, FC, or F77 caused the build to exit with a warning. Then allow an environment variable like SAGE_ALLOW_SETTING_OF_COMPILERS (better name?) that will allow someone to do this, if they really want to. The same is true really of CP, CHMOD and several other variables. They work in some parts of Sage, and not in others. Dave Another possibility might be that if the Sage build system starts and the environment variable CC is defined, then a command "gcc" that runs whatever is specified in CC is created and put first in the path. Then: (1) any build scripts that still annoying look for gcc will instead find this fake gcc wrapper and use it, hence calling CC. (2) We can also make it so this fake gcc wrapper logs whenever it is called, and hence easily nail down which packages are offendors. The same can be done with all the other variables you mentioned. -- William I don't like the fake gcc idea myself. Currently when the fake gcc is run, it obscures what flags are being passed to the compiler - the same with the sage_fortran. We already have one fake gcc, so then we need another one which logs data. We have a sage_fortran, but then we need a sage_fortran which is really a fake fortran compiler. IMHO, a simple warning is better. That leaves any messing around with logs in the hands of the developer who is trying to sort out the problems with the variables. He might prefer to abort at that point, rather than log data data. If you tried to link object files created from C++ code from the Sun and GNU compilers, it would certainly end in disaster, to aborting is probably safest. BTW, do we really need a sage_fortran any more? I believe at one point the reason was there was the possibility of the compiler being g95 or gfortran, but I believe that is dropped now, and only gfortran will be used. So why not call gfortran directly? 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
Re: [sage-devel] Should we block the use of CC and CXX except for developers?
On Mon, Jun 14, 2010 at 3:49 AM, Dr. David Kirkby wrote: > The recent thread: > > "Error building Sage 4.4.3 under vanilla Debian lenny amd64: Error while > installing flint" > > http://groups.google.com/group/sage-devel/browse_thread/thread/54531b50412b9882/2f45257c5e56ab00?lnk=gst&q=Error+building+Sage+4.4.3+under+vanilla+Debian+lenny+amd64%3A+Error+while+installing+flint#2f45257c5e56ab00 > > > is an example of where someone had a broken installation of Debian > (different versions of gcc and g++), so got an error from the 'prereq' > script, which I altered some time ago to detect different versions and exit. > > The poster then went on to try to get CC and/or CXX in order that he got the > same (older) versions of both. > > Such a plan will never work in Sage, as numerous bits of code make direct > calls to "gcc" or "g++" and ignore the environment variables. So any attempt > to do this results on C compiler being used to build one bit of Sage, and > another to build another bit of Sage. That seems a recipe for disaster. > > Hence I'd propose that any attempt to set CC, CXX, FC, or F77 caused the > build to exit with a warning. Then allow an environment variable like > > SAGE_ALLOW_SETTING_OF_COMPILERS > > (better name?) > > that will allow someone to do this, if they really want to. > > Not letting people set CC or similar seems a bit dumb, as it is very useful > for some sort of debugging, or porting to Sun Studio. But it is pretty > dangerous for a typical user to do, as it will never work as they would > expect. > > The same is true really of CP, CHMOD and several other variables. They work > in some parts of Sage, and not in others. > > Dave Another possibility might be that if the Sage build system starts and the environment variable CC is defined, then a command "gcc" that runs whatever is specified in CC is created and put first in the path. Then: (1) any build scripts that still annoying look for gcc will instead find this fake gcc wrapper and use it, hence calling CC. (2) We can also make it so this fake gcc wrapper logs whenever it is called, and hence easily nail down which packages are offendors. The same can be done with all the other variables you mentioned. -- William -- 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
[sage-devel] Should we block the use of CC and CXX except for developers?
The recent thread: "Error building Sage 4.4.3 under vanilla Debian lenny amd64: Error while installing flint" http://groups.google.com/group/sage-devel/browse_thread/thread/54531b50412b9882/2f45257c5e56ab00?lnk=gst&q=Error+building+Sage+4.4.3+under+vanilla+Debian+lenny+amd64%3A+Error+while+installing+flint#2f45257c5e56ab00 is an example of where someone had a broken installation of Debian (different versions of gcc and g++), so got an error from the 'prereq' script, which I altered some time ago to detect different versions and exit. The poster then went on to try to get CC and/or CXX in order that he got the same (older) versions of both. Such a plan will never work in Sage, as numerous bits of code make direct calls to "gcc" or "g++" and ignore the environment variables. So any attempt to do this results on C compiler being used to build one bit of Sage, and another to build another bit of Sage. That seems a recipe for disaster. Hence I'd propose that any attempt to set CC, CXX, FC, or F77 caused the build to exit with a warning. Then allow an environment variable like SAGE_ALLOW_SETTING_OF_COMPILERS (better name?) that will allow someone to do this, if they really want to. Not letting people set CC or similar seems a bit dumb, as it is very useful for some sort of debugging, or porting to Sun Studio. But it is pretty dangerous for a typical user to do, as it will never work as they would expect. The same is true really of CP, CHMOD and several other variables. They work in some parts of Sage, and not in others. 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
