SEP
Ralf Hemmecke
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
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.
--Ralf
Robert Bradshaw
> 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
Dr. David Kirkby
> 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
William Stein
> 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
Ralf Hemmecke
>> 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?
Can you tell me what you need? If I invest any time in figuring out a
proper bug description, I'll probably find and fix the bug myself.
The problem is that with every call of sage (and sub-scripts) sage tries
to figure out what SAGE_ROOT is. I haven't set SAGE_ROOT. (Why should I
clutter up my environment? I expect sage to work properly without
setting SAGE_ROOT.) I consider this behaviour of sage wrong by design,
so I wrote a SEP. But that's just me and so I'll shut up.
Ralf
Ralf Hemmecke
>
> 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
Ralf Hemmecke
> 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
Ralf Hemmecke
> 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
Dr. David Kirkby
>>> 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<lib dir> if you have libraries in a
nonstandard directory <lib dir>
CPPFLAGS C/C++ preprocessor flags, e.g. -I<include dir> if you have
headers in a nonstandard directory <include dir>
CXX C++ compiler command
CXXFLAGS C++ 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
Robert Bradshaw
>>> 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?
>
> Can you tell me what you need? If I invest any time in figuring out a
> proper bug description, I'll probably find and fix the bug myself.
I was just wondering if there was a clear way to reproduce it, but it
sounds like something more subtle.
> The problem is that with every call of sage (and sub-scripts) sage
> tries
> to figure out what SAGE_ROOT is. I haven't set SAGE_ROOT. (Why
> should I
> clutter up my environment? I expect sage to work properly without
> setting SAGE_ROOT.)
+1, that's what I expect too.
> I consider this behaviour of sage wrong by design,
> so I wrote a SEP. But that's just me and so I'll shut up.
I think it's useful to have a *single* entry point where SAGE_ROOT
(and SAGE_LOCAL, etc.) are all resolved and defined, as well as all
paths and other necessary bits, and from there on the sub-scripts
don't have to worry about it. If this is being figured out in multiple
places, I see that as a problem too.
- Robert
William Stein
<robe...@math.washington.edu> wrote:
> On Jun 2, 2010, at 4:42 AM, Ralf Hemmecke wrote:
>
>>>> 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?
>>
>> Can you tell me what you need? If I invest any time in figuring out a
>> proper bug description, I'll probably find and fix the bug myself.
That doesn't sound like a bad outcome :-)
>
> I was just wondering if there was a clear way to reproduce it, but it sounds
> like something more subtle.
>
>> The problem is that with every call of sage (and sub-scripts) sage tries
>> to figure out what SAGE_ROOT is. I haven't set SAGE_ROOT. (Why should I
>> clutter up my environment? I expect sage to work properly without
>> setting SAGE_ROOT.)
>
If Sage is properly installed, it will.
>> I consider this behaviour of sage wrong by design,
>> so I wrote a SEP. But that's just me and so I'll shut up.
>
>
> I think it's useful to have a *single* entry point where SAGE_ROOT (and
> SAGE_LOCAL, etc.) are all resolved and defined, as well as all paths and
> other necessary bits, and from there on the sub-scripts don't have to worry
> about it. If this is being figured out in multiple places, I see that as a
> problem too.
This is also important to being able to move an installed copy of Sage.
-- William
>
> - Robert
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
Robert Bradshaw
>>> 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
Aleksej Saushev
Ralf Hemmecke <hemm...@gmail.com> writes:
>> 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.)
This is common delusion. Unfortunatly, you'll find that you need some
understanding how autotools work (let alone having them installed)
pretty soon after you start working with software. There's alternative
way when you do something similar yourself, sure, but then you need some
acquaintance with autotools just not to repeat its mistakes.
Good joke on what we do: http://xkcd.com/754/
--
HE CE3OH...