#8059: update Singular SPKG to newest upstream release
-------------------------------+--------------------------------------------
Reporter: malb | Owner:
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-4.5
Component: packages | Keywords:
Author: Martin Albrecht | Upstream: Fixed upstream, in a later
stable release.
Reviewer: | Merged:
Work_issues: |
-------------------------------+--------------------------------------------
Changes (by drkirkby):
* cc: fbissey (added)
Old description:
> The Singular team accepted most of our patches upstream. They are in the
> 3-1-0-9 release, which also is a first step to make things easier for
> library developers.
New description:
The Singular team accepted most of our patches upstream. They are in the
3-1-0-9 release, which also is a first step to make things easier for
library developers.
--
Comment:
Replying to [comment:53 malb]:
> I've updated the Singular SPKG to 3-1-1-3 which fixes the genus issue.
However, this release segfaults a lot! I'm in the process of resolving
this (cf. [libsingular-devel])
>
> http://sage.math.washington.edu/home/malb/spkgs/singular-3-1-1-3.p0.spkg
Hi Martin Albrecht ,
A few comments.
* Is it possible you could request the upstream developers distribute the
source code so the files generated by tools like autoconf, flex, actually
have later modification times of the generated file newer than the file
they are generated from?
Currently libparse.cc, which is the output from 'flex' has exactly the
same modification time (to the ns) as the file it was supposedly generated
from (libparse.l). I doubt 'flex' actually run in < 1 ns!
{{{
-rw-r----- 1 drkirkby staff 109422 2010-02-03 13:58:03.000000000
+0000 src/Singular/libparse.cc
-rw-r----- 1 drkirkby staff 30875 2010-02-03 13:58:03.000000000
+0000 src/Singular/libparse.l
}}}
Likewise for these files. Clearly autoconf did not run in under a ns.
{{{
-rwxr-x--- 1 drkirkby staff 85614 2010-03-03 11:36:23.000000000
+0000 src/factory/configure
-rw-r----- 1 drkirkby staff 13992 2010-03-03 11:36:23.000000000
+0000 src/factory/configure.in
}}}
This will save us having to 'touch' the files.
* There's a problem with the {{{build()}}} part of spkg-install.
The script author probably assumes that if any one of the items in
{{{build()}}} fail, then {{{build()}}} will fail and so the error will be
reported. However, that is not the case. As long as the last item in
{{{build()}}}, which is ({{{install_docs}}}), does not fail, the return
code from {{{build()}}} will be 0. So if for example I modify the
{{{build()}}} section to:
{{{
build()
{
clean_headers
# This SHOULD break the build
rm /non-existant-file
patch
distclean
config
build_singular
build_libsingular
build_factory
build_libfac
create_singular_script
install_docs
}
build
if [ $? -ne 0 ]; then
echo "Error somewhere building Singular."
exit 1
fi
}}}
then when I build Singular, I see:
{{{
Building a 64-bit version of Singular
rm: /non-existant-file: No such file or directory
make: *** No rule to make target `distclean'. Stop.
creating cache ./config.cache
checking uname for singular... ix86-SunOS
checking for gcc... gcc -m64
...
Successfully installed singular-3-1-1-3.p1
}}}
In other words, the error of trying to delete /non-existant-file does not
cause the build to fail, as it should do. That means if the library fails
to build, but the docuemtation installs ok, then the script will not show
the error. Each part should be checked individually.
I've not checked this, but believe the following would work:
{{{
build()
{
for i in clean_headers patch distclean config build_singular
build_libsingular build_factory build_libfac create_singular_script
install_docs ; do
$i
if [ $? -ne 0 ]; then
echo "Error building Singular when running '$i'."
exit 1
fi
done
}
}}}
* There are in fact a lot of parts in spkg-install which are not checked
for errors.
* François Bissey has said the previous version of Singular built some
unnecessary targets, which adds to the build time of Singular. Given this
is the longest package to build (taking almost 6 minutes on my PC), it
would be worth reducing them if you have not already done so. I've cc'ed
François on the ticket, as he knows a lot more about this package than me.
* It does built on !OpenSolaris, though I've not checked it on anything
else. I'll wait until you have sorted out the segfaults first!
PS, The first 3-1-1-3 to go into Sage should be called
singular-3-1-1-3.spkg and not have a '.p0' in the name.
Dave
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/8059#comment:54>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
