Re: [sage-devel] SEP
On Jun 2, 2010, at 4:43 AM, Ralf Hemmecke wrote: http://wiki.sagemath.org/AutoToolsSEP My primary concern with both of these proposals is that they seek to widen the gap between developers and users, Huh? E.g. "The command sage should run Sage and not be misused for development processes." which is assumed throughout both proposals. and I think a huge part of Sage's success in attracting contributors is erasing that gap. Sage is not a sucess for me as I stumple from bug to bug. I'm sorry to hear that, are you filing reports? At least you have the option of fixing them if you can. Want to fix a bug? Just edit the source, type "sage -br", and you're good to go. Want to fix a bug? Just edit the source, type "make && make install" and restart sage. While that may be more natural for you as a software developer, it's quite a mouthful to if you've never used all these tools before. You also forgot the "cd into the right directory and set up all environment and path variables first." Note that sage -b builds/ installs the sage library only (no makefile here, uses Python's equivalent), and finishes very quickly if there are only modifications to Python files, whereas a (massively recursive) make, even if nothing changed, would take a long time. A little bit more about revision control, and you've got a patch up on trac. Oh, you've forgotten to create an account and login, reading the trac guidelines and figuring out what trac is all about. ;-) Yeah, there's the whole non-technical side of things to learn too. All of this (fortunately) requires no knowledge of autoconf/make/setup.py/environment variables/paths/etc. Ehm, does calling "make && make install" or even "./configure && make && make install" require you to know about the existence of autotools/ automake? Do you know that the standard packages mpir and gnutls use automake+autoconf. Yep. If an upstream project is using autoconf, we'll use it too. (If it doesn't, we'll probably stick with whatever build system it does have, rather than maintain our own). It is definitely the a good tool for some jobs. http://git.savannah.gnu.org/cgit/gnutls.git/tree/Makefile.am http://boxen.math.washington.edu/svn/mpir/mpir/trunk/Makefile.am There are probably more of this sort. Still, someone that installs mpir doesn't need to have autoconf or automake installed on his/her computer. Why? Read the documentation of autoconf. Cannot just everyone from sage-devel think about requirements for the build process and write that down at http://wiki.sagemath.org/AutoToolsSEP or Done. http://wiki.sagemath.org/UnifiedCommandLineSEP ? Having proper requirements would already be a step forward of cleaning up, right? I actually don't understand why there is so much opposition against autotools. Three people replied so far, three times it's against. Is it because the build-system of sage is already perfect and I just cannot see it? Then it's just me and I must live with the fact that sage doesn't work as expected for me. I think it's fair to say there's not a lot of love for autotools, it's more regarded as a necessary evil. Certainly the current build system is not perfect, but it's unclear what advantages autoconf brings to the table. Autoconf seems more for building C code, not for managing software distributions (which is essentially the role of the top-level build script). - 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] SEP
On 06/ 2/10 12:42 PM, Ralf Hemmecke wrote: http://wiki.sagemath.org/AutoToolsSEP One problem with that is that too many packages in Sage do not honor things like CC, MAKE, CXX. Cython misbehaves if CFLAGS set. What does that have to do with autotools? If the subpackages misbehave then one has to provide proper fixes with or without autotools, right? I'm not anti auto-tools myself. I've written software using them, and have maintained Sage's "prereq" script which is autoconf based, to check for the existence of a semi-sensible build environment. My point is as soon as you present something with a 'configure' script which says something like ... Some influential environment variables: CC C compiler command CFLAGS C compiler flags LDFLAGS linker flags, e.g. -L if you have libraries in a nonstandard directory CPPFLAGSC/C++ preprocessor flags, e.g. -I if you have headers in a nonstandard directory CXX C++ compiler command CXXFLAGSC++ compiler flags AR AR for the host AS AS for the host then people would expect that by setting CC, they could set the C compiler they can use. Well they can't. It would be a *huge* undertaking to rid Sage of all the bad code that would allow autotools to work as they are intended. So any hope of using autoconf/automate and thinss working as those packages intend will fail. So you will never get a conventional autoconf/automake build process. Right! Computers will *never* be able to deal with anything but numbers. Of course sage might never have autotools. Not because it doesn't work, but rather because some people hear autotools and are already against. I'm not one of those. Whatever their faults, they still seem to me the most reliable build tool. I don't know much about libtool I would admit. Python, Apache, gcc etc etc all use autotools. Sage builds gnutls and mpir as standard spkgs. Both of them use autotools. Why haven't you realized it? And why will no user ever realize it? I'm well aware some packages use auto-tools. Even some that do use them, do it extremely poorly. Take a look at the file Makefile.am in cddlib. It starts with "Site customizations:" which should not be necessary. The author clearly did not know what he/she was doing using autotools. It would probably be even more confusing, as people would expect Sage to build like other packages. Exactly, I expect, "./configure&& make&& make install". Who wouldn't? Ralf you forgot make check! 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] SEP
> For the reasons Robert Bradshaw mentioned, I don't think the AutoTools > SEP makes a lot of sense for Sage. Robert also added "Automake would add another level of complexity to the build process, in particular one which is not understood by many in the community." to http://wiki.sagemath.org/AutoToolsSEP. How many people understand Sage's build process? Would be interesting to have a poll on that. An ordinary developer would never have to deal with automake/autoconf. He/she would not even have the need to install autotools on their computer. (Although it is not a big deal to install them with newer linux distributions.) >> http://wiki.sagemath.org/UnifiedCommandLineSEP > > Perhaps this has already been adequately addressed by recent work of > John Palmieri: > > http://trac.sagemath.org/sage_trac/ticket/21 Why do you think have I cited exactly that link at http://wiki.sagemath.org/UnifiedCommandLineSEP ? Ralf -- 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] SEP
>> http://wiki.sagemath.org/AutoToolsSEP > My primary concern with both of these proposals is that they seek to > widen the gap between developers and users, Huh? > and I think a huge part of Sage's success in attracting contributors > is erasing that gap. Sage is not a sucess for me as I stumple from bug to bug. > Want to fix a bug? Just edit the source, type "sage -br", and you're > good to go. Want to fix a bug? Just edit the source, type "make && make install" and restart sage. > A little bit more about revision control, and you've got > a patch up on trac. Oh, you've forgotten to create an account and login, reading the trac guidelines and figuring out what trac is all about. ;-) > All of this (fortunately) requires no knowledge > of autoconf/make/setup.py/environment variables/paths/etc. Ehm, does calling "make && make install" or even "./configure && make && make install" require you to know about the existence of autotools/automake? Do you know that the standard packages mpir and gnutls use automake+autoconf. http://git.savannah.gnu.org/cgit/gnutls.git/tree/Makefile.am http://boxen.math.washington.edu/svn/mpir/mpir/trunk/Makefile.am There are probably more of this sort. Still, someone that installs mpir doesn't need to have autoconf or automake installed on his/her computer. Why? Read the documentation of autoconf. Cannot just everyone from sage-devel think about requirements for the build process and write that down at http://wiki.sagemath.org/AutoToolsSEP or http://wiki.sagemath.org/UnifiedCommandLineSEP ? Having proper requirements would already be a step forward of cleaning up, right? I actually don't understand why there is so much opposition against autotools. Three people replied so far, three times it's against. Is it because the build-system of sage is already perfect and I just cannot see it? Then it's just me and I must live with the fact that sage doesn't work as expected for me. Ralf -- 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] SEP
>> http://wiki.sagemath.org/AutoToolsSEP > > One problem with that is that too many packages in Sage do not honor > things like CC, MAKE, CXX. Cython misbehaves if CFLAGS set. What does that have to do with autotools? If the subpackages misbehave then one has to provide proper fixes with or without autotools, right? > So any hope of using autoconf/automate and thinss working as those > packages intend will fail. So you will never get a conventional > autoconf/automake build process. Right! Computers will *never* be able to deal with anything but numbers. Of course sage might never have autotools. Not because it doesn't work, but rather because some people hear autotools and are already against. Sage builds gnutls and mpir as standard spkgs. Both of them use autotools. Why haven't you realized it? And why will no user ever realize it? > It would probably be even more confusing, as people would expect Sage > to build like other packages. Exactly, I expect, "./configure && make && make install". Who wouldn't? Ralf -- 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] SEP
On Tue, Jun 1, 2010 at 3:15 PM, Ralf Hemmecke wrote: > Hello, > > today, running "./sage -t filename" did not succeed on my system. After > a while, I could figure out with some help of Burcin that my setup of > sage was too much using symbolic links. In fact, after I removed "sage" > from being available via PATH, the above command succeeded. > > Since that is not the first time I run into that problem, I started to > write two SEPs. > > http://wiki.sagemath.org/AutoToolsSEP For the reasons Robert Bradshaw mentioned, I don't think the AutoTools SEP makes a lot of sense for Sage. > http://wiki.sagemath.org/UnifiedCommandLineSEP Perhaps this has already been adequately addressed by recent work of John Palmieri: http://trac.sagemath.org/sage_trac/ticket/21 > > I'd be happy if some of you could comment on it and improve that pages. > Before any implementation starts, there should be a clearer specification. > -- 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] SEP
On 06/ 1/10 11:15 PM, Ralf Hemmecke wrote: Hello, today, running "./sage -t filename" did not succeed on my system. After a while, I could figure out with some help of Burcin that my setup of sage was too much using symbolic links. In fact, after I removed "sage" from being available via PATH, the above command succeeded. Since that is not the first time I run into that problem, I started to write two SEPs. http://wiki.sagemath.org/AutoToolsSEP One problem with that is that too many packages in Sage do not honor things like CC, MAKE, CXX. Cython misbehaves if CFLAGS set. So any hope of using autoconf/automate and thinss working as those packages intend will fail. So you will never get a conventional autoconf/automake build process. It would probably be even more confusing, as people would expect Sage to build like other packages. 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] SEP
On Jun 1, 2010, at 3:15 PM, Ralf Hemmecke wrote: Hello, today, running "./sage -t filename" did not succeed on my system. After a while, I could figure out with some help of Burcin that my setup of sage was too much using symbolic links. In fact, after I removed "sage" from being available via PATH, the above command succeeded. Could you elaborate? Since that is not the first time I run into that problem, I started to write two SEPs. http://wiki.sagemath.org/AutoToolsSEP http://wiki.sagemath.org/UnifiedCommandLineSEP I'd be happy if some of you could comment on it and improve that pages. Before any implementation starts, there should be a clearer specification. Sure. I'll comment here, as it the mailing list is more conducive to discussion, though any consensus should be recorded back into the wiki. My primary concern with both of these proposals is that they seek to widen the gap between developers and users, and I think a huge part of Sage's success in attracting contributors is erasing that gap. Want to fix a bug? Just edit the source, type "sage -br", and you're good to go. A little bit more about revision control, and you've got a patch up on trac. All of this (fortunately) requires no knowledge of autoconf/make/setup.py/environment variables/paths/etc. Moving away from this would be a step in the wrong direction 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
