As a first step I have made a new ticket for an improved spkg, which has "make check" test set in the makefile. If that looks OK I will try to get it merged upstream.
So I would appreciate it if anyone can review #5018: http://trac.sagemath.org/sage_trac/ticket/5018. Marshall On Jan 18, 11:22 am, mabshoff <mabsh...@googlemail.com> wrote: > On Jan 18, 8:43 am, mhampton <hampto...@gmail.com> wrote: > > > On Jan 17, 8:44 pm, mabshoff <mabsh...@googlemail.com> wrote: > > Hi Marshall, > > > > If you look at the Makefile of this code you should clearly see that > > > it needs cleaning up and rewriting it from scratch in this case might > > > be easier since only a couple files are involved. On problem right off > > > the bat is that compiler as well as build flags are hard coded for > > > each file. So if you do something about that and add tests someone > > > might as well as put files into proper directories, etc. > > > I think you already dealt with the hard-coded locations in the current > > makefile in the optional package. Its unclear to me what else needs > > to be done in that regard. > > I need to look at it some more since I only looked at the upstream > sources. But the Makefile can certainly be simplified. > > > I will communicate with David Avis about adding make check targets > > upstream, and whether the 2006 is the "latest and greatest". I > > strongly suspect that it is - the recent changes just add on a little > > functionality, the primary algorithm has been stable for a while. > > > > And lrs can be build as a library and probably will so be integrated > > > in Sage in the future. Since there are issues with LLP64 this is not a > > > fun thing to debug, ... > > > At the moment I am not using it as a library. In the future it would > > make sense to do so though - I think Sébastien Barthélemy is working > > on converting my crude cddlib interface to a library use, and I hope > > to fully understand what he does so that I can do similar things with > > lrs. > > Yes, but even not as a library the code should compile in 64 bit mode > on a LLP64 platform. Because if no one is paying attention a patch to > use lrs as a library can slip in and all the sudden someone has to fix > another potential problem. This also applies to cddlib, but that one > has the obvious benefit of being "grandfathered" in. > > > I don't understand the LLP64 issues you are referring to - is that a > > problem for a windows port or would it affect other things? If you > > can clarify a bit what causes those issues I am willing to try to fix > > them for lrs. > > LLP64 means that a 64 bit pointer is represented by a long long. The > only relevant architecture here is Windows. Microsoft decided way back > in order not to break their API in 64 bit mode sizeof(long) should > stay 4 bytes. But many people assume in their code that sizeof(long) > is 8 bytes on a 64 bit platform. Recent (and probably not so recent) C > as well as C++ standards spell out that this is not a requirement, but > that a case like > > void -> intptr -> void > > for example for C does not truncate. Something analog applies to C++ > where size_t is guaranteed to be large enough to address the given > address space on the box. The above might be a little off, but it is > the gist. > > I cannot point at a specifi LLP64 problem with lrs since I only > skimmed the code and then wiped the sources locally and I am insanely > busy until I leave for SD 12, but if you put together a test suite I > can take MSVC 2008 and build lrs in 64 bit mode on Windows and tell > you if we are running into any trouble. > > > Marshall > > Cheers, > > Michael --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
