This approach might not be pretty, but it seems to work fine. I can use cysignals on cygwin, linux, mac and not use it on windows without cygwin.
However, it would be much nicer to allow pip installing cysignals on windows without cygwin in the first place. This would simplify this a lot. jonatha...@googlemail.com schrieb am Mittwoch, 10. März 2021 um 17:44:05 UTC+1: > Here is my project (I just made the repository public): > https://github.com/kliem/PyKPartiteKClique/tree/main/ > > The source folder is kpkc > > As you can see, I completely copied memory_allocator* > > This should be moved to its own project eventually. > > Instead of cimporting directly from cysignals (which may fail, if not > present), I cimport from kpkc.cysignals > > There are two files for this. kpkc/cysignals.pyx which is a plain > wrapper about the cysignals functions (just cimporting did not work). > > If cysignals is not present, I instead compile kpkc/cysignals_backup.pyx > as module kpkc.cysignals. > > Of course, you need to reinstall the project, if you install cysignals > afterwards. > > On 10.03.21 16:07, E. Madison Bray wrote: > > On Wed, Mar 10, 2021 at 3:51 PM 'Jonathan Kliem' via sage-devel > > <sage-...@googlegroups.com> wrote: > >> What I'm struggling with is the following: > >> > >> How do I cimport from different sources (runtime dependent probably > >> won't work, but compile time dependent would already be nice). At the > >> moment my package just pulls in cysignals during pip install and if this > >> does not work it replaces those functions by standard allocation > functions. > >> > >> Is there a better solution to do this? > > What do you mean by "cimport from different sources"? If you are > > already working on this could you link to the source? > > > > If this is about my idea to make the memory allocation functions > > "pluggable" that would be done by setting some function pointers to > > them, which would be done by third-party Cython code using > > MemoryAllocator (there would need to be a C method for setting them). > > > >> On 10.03.21 15:27, E. Madison Bray wrote: > >>> On Sat, Feb 13, 2021 at 2:16 AM Matthias Koeppe > >>> <matthia...@gmail.com> wrote: > >>>> On Friday, February 12, 2021 at 2:35:45 PM UTC-8 vdelecroix wrote: > >>>>> Why make it part of cysignals? The purpose of the memory allocator > >>>>> is quite distinct from cysignals. Merging them look artificial to me. > >>>> Really? MemoryAllocator is just a wrapper class around > cysignals.memory > >>> Was there ever any action on this? MemoryAllocator does seem like a > >>> useful thing to have as an independent package. It's basically a more > >>> sophisticated version of the SomeMemory recipe given in the Cython > >>> docs: > https://cython.readthedocs.io/en/latest/src/tutorial/memory_allocation.html > >>> > >>> I agree that it's distinct from cysignals. It doesn't necessarily > >>> have to depend on cysignals, and could have a hook interface to allow > >>> different memory allocation functions. It just happens to use the > >>> ones from cysignals since Sage already uses cysignals, and its memory > >>> functions have the advantage of being interrupt-safe. > >>> > >>> I would continue using cysignals by default for an initial > >>> implementation, but if anyone had a need for it, it would be possible > >>> to make this work with cysignals as an optional dependency as well. > >>> > >> -- > >> You received this message because you are subscribed to the Google > Groups "sage-devel" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an email to sage-devel+...@googlegroups.com. > >> To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/58a5c332-7331-8433-941e-b73f7090d608%40gmail.com > . > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/c97629a6-d418-4ebc-99f6-e6305778abbdn%40googlegroups.com.
