On 06/ 6/10 04:43 PM, leif wrote:
On 6 Jun., 12:27, Willem Jan Palenstijn<w...@usecode.org> wrote:
The way this usually works is that packages are shipped with the output of
flex, so that flex doesn't have to be run again if the user doesn't have it.
This is a more general problem ([f]lex and yacc/bison are just
examples; the auto-tools are another one).
Anyone who includes/updates an spkg should make sure that no
"developer tools" are required to perform a conventional "user" build/
install, i.e.:
- the pregenerated files are included in the source tarball,
- file modification times do not cause unintended dependencies/
rebuild of provided files.
Unfortunately the sections on spkgs in the Developer's Guide have been
split into creation of new and update/patching of existing spkgs
("Producing New Sage Packages" [2], "Patching a Sage Package" [3]);
I'm not sure if everybody will read the introductory "Disseminating
Code for Sage" [1]. Perhaps a hint in potentially affected spkgs'
SPKG.txt wouldn't be bad, too.
(The file permissions/ownership issue could also be mentioned in these
sections.)
-Leif
[1]
http://www.sagemath.org/doc/developer/disseminating_code.html#disseminating-code-for-sage
[2]
http://www.sagemath.org/doc/developer/producing_spkgs.html#producing-new-sage-packages
[3]
http://www.sagemath.org/doc/developer/patching_spkgs.html#patching-a-sage-package
The section "Disseminating Code for Sage" does seem rather mis-placed to me,
though I can't think of how I would improve it.
Things like creating .spkg's should arguably not be subsections of
"Disseminating Code for Sage"
The section about .spkg's called "Avoiding trouble" could certainly do with
expansion on these issues.
http://www.sagemath.org/doc/developer/producing_spkgs.html#avoiding-troubles
It's only seven sentences long. It should certainly state that programs used by
developers (yacc, lex, bison, flex, autoconf, automake should not be assumed to
be available). However, from discussions on sage-support, the optional package
Lie needs bison. Perhaps the bison output for that could be added into the
package, so one does not need bison. I don't know how practical that would be,
and given it is an optional package and has a more fundamental flaw, I can't be
bothered to try to do anything about that - installing bison would be easiest.
I doubt however there is much a Sage developer could have done to notice the
problem with Singular. In general, they are not going to look into the source
code of the individual packages, and compare time stamps on files. Even if they
do, with 'ls -l' they are not going to see that a file is one second older than
another, as the dates are back in 2008 and this information is not shown in the
normal output of 'ls'. How many of them will know what 'yacc' and 'lex' do
anyway? (Or their GNU clones 'bison' and 'flex').
Some things I look at in Sage and wonder how anyone could be so stupid to miss.
In this case, I don't think any Sage developer can be blamed. I suspect they
have untarred the Singular source code, so the dates have remained what they
originally were.
Anyway, it is good that it is found.
Could I twist your arm to review the changes?
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
