On 6 Jun., 19:02, "Dr. David Kirkby" <david.kir...@onetel.net> wrote: > On 06/ 6/10 04:43 PM, leif wrote: > > [1]http://www.sagemath.org/doc/developer/disseminating_code.html#dissemi... > > [2]http://www.sagemath.org/doc/developer/producing_spkgs.html#producing-... > > [3]http://www.sagemath.org/doc/developer/patching_spkgs.html#patching-a-... > > The section "Disseminating Code for Sage" does seem rather mis-placed to me, > though I can't think of how I would improve it.
Most probably Minh will have some good ideas.. :) > 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. Thought of that, too, but it should be in both subsections :-/ > http://www.sagemath.org/doc/developer/producing_spkgs.html#avoiding-t... > > 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. Just for the record, some packages (I don't think in Sage) require skeleton files or even libraries, too (i.e. providing the pregenerated files does not always suffice). > I doubt however there is much a Sage developer could have done to notice the > problem with Singular. make -n ? ;-) (aka --dry-run) (Obviously this depends on the system as well; usually one had to run ./configure before...) perhaps grep <tool> in (test) install.log (testing on mostly vanilla "user" installations is another option) > 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. Yes, but "touch" in spkg-install is an ugly workaround (to be removed in the long run), not a bugfix. ;-) > Could I twist your arm to review the changes? Be a little patient, awaiting 4.4.4.alpha0... (And in principle the patch should be tested on other Solaris systems, too... I currently can only give it a "Linux-ok" - as soon as the sysloads drop reasonably...) -Leif -- 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
