On 31 Jan 2005, at 08:37, Martin Costabel wrote:
Daniel Henninger wrote:[]Update of /cvsroot/fink/dists/10.3/unstable/main/finkinfo/sci In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv927 Added Files: singular.info Log Message: Added per tracker id 1109172.BuildConflicts: broken-gcc, singular-factory, singular-libfac
Did you contact the maintainer (drm) of singular-factory and singular-libfac about this? Is there a possibility to have these things coexist? AFAICT, they don't install the same things with the same names, or at least not at the same place (libcf.a and libfac.a are now called libsingcf.a and libsingfac.a, respectively, and the headers and templates are in /sw/include/Singular instead of /sw/include).
Or does can new singular package provide a drop-in replacement that could be used for macaulay2 instead of the others?
Or why is there a build conflict anyway?
Sorry to have been absent for a couple of days.
As David mentioned, I have a singular-2.06 pkg in my exp tree ( + minor further modifications in local)
I see 2 major problems with the present submission :
a) It violates FS-layout policy : the binaries are not in bin; further only one of them has a link in bin
b) It is broken:
I commented out in the CompileScript the 2 lines that remove a doc dir, removed the
"--disable-doc" in the configure line (such a pkg really needs its docs, and building them is one way to test ...) , and added the following 3 lines at the end of the installscript, to run
"make test" (this requires the full LIB, not just the subset that was installed):
rm -fR %/share/Singular/LIB
cp -pPR Singular/LIB %i/share/Singular
time make Tst-All
Then already the building of doc bombed out (seg_fault in examples/groebner.sing), and the tests showed :
universal Summary: Checks:329 Failed:11 Time:208.34
ok_s Summary: Checks:125 Failed:20 Time:389.27
ok_l Summary: Checks:57 Failed:17 Time:3054.68
(The tests are (mostly at least) the same as in the 2.06 version, and the pkg in my exp dir
doesn't fail any one of them _ even on a larger set of tests.)
(I think pkg's like this should run "make test" systematically _ or at least have a couple of lines to uncomment in order to do "make test" _: they are very prone to errors that show up
only at runtime, in very specific circumstances, and which come and go with the slightest
variation in compiler _ or in compiler flags).
For those 2 reasons I think the pkg must be pulled for the moment _ it can only mislead
users into believing results are true when they are not (in the ok_l list 1 computation out of 3 is wrong !) .
The maintainer can have my pkg in exp to use for the moment as plugin (maybe until version 3.0 ?)_ it needs minor polishing for that, but I can help him with it.
That one satisfies FS-policy, builds including its docs and emacs dirs, passes all tests
(and seems much faster: eg, on the same "universal" tests, I get a time of ~130, as compared to 208; also much smaller: the main executable is less than half the size;
and finally has a variant 'with dynamic kernel')
Jean-Francois
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Fink-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fink-devel
