Ximin Luo writes:
> We can do "pre-install tests" with Sage 7.3, by doing a "dummy
> install" using Sage's Makefiles, running the tests here, then
> installing them to the "real location". (This requires some patching,
> but we have achieved this already and it works.) However with Sage 7.4
> this is not possible, due to the fpylll situation. Packages in Debian
> (and most other buildsystems) are built and tested as distinct units,
> we can't build A, install A, build B, install B, then test A.
I see the problem here.
> So, a much better alternative of resolving the fpylll issue would be
> to not have fpylll build-depend on Sage.
> (1) I can see that it's possible to build fpylll without Sage, it will
> just have a different API. Could we patch Sage-the-library to use
> fpylll-without-Sage, then have Sage itself convert the non-Sage
> integers into Sage integers?
> So, what are the problems with (1)? If there are no problems, could we
> patch this *before* Sage 7.4 is released? I would be happy to write
> the patch myself, but guidance on where to start would also be much
It’d be easy to make that work as far as tests are concerned, we’d lose
convenience, though: none of the fpylll functions taking integer
arguments would work out of the box.
Alternatively, we could do the conversion on the Python level instead of
C/C++/Cython. This way, it could be resolved at runtime. There’d be some
overhead, but the Integer conversion functions aren’t really used all
I’ll give that a try.
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to firstname.lastname@example.org.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.