[discussion] Sharing custom C modules is hard #4001
Comments
|
There are two (mostly orthogonal) proposals to fix this:
Note that both solve roughly the same problem, they do it in very different ways and are targeted at slightly different audiences / types of modules, so I think it's valuable to have both. |
|
Hmm, your solution (#3871) looks like it would fit what I was expecting. Pity it hasn't been merged yet. I'll keep my eyes on that PR.... |
That's what CMake does (and other systems): generate |
stinos@e858818 is similar to the CPython way of loading dynamic libraries, so you give someone a Makefile and a bunch of C (or C++) code which creates a .so which can then be imported as a module. Only tested on unix and windows, not sure how it compares to the other solutions. |
|
While I am a big fan of the idea of dynamic C modules, they will always have a ram overhead in the same way as loading an mpy file from filesystem vs frozen bytecode. Anything that's a file on the filesystem needs to be first read into ram before it can be run. For some applications, dynamic modules will be great, making it simple to add functionality without needing to recompile and flash micropython. For others, the lower overhead of compiled in functions will work better. I definitely support having both options available! |
Not true. With a few changes, |
|
Hmm.. I'd say this would require a filesystem that guarantees that a file is in one contiguous (aligned?) block to be able to execute directly from it, if that's the case then sure, it should work. That's not always the case though, files are often split over multiple blocks / sectors in a filesystem. tbh I'm not sure about the FatFS implementation currently used, though I'm pretty certain littlefs does not work this way if we do switch to that. |
|
Support for custom user C modules was added in 2e51607. Also, MicroPython now supports dynamically loadable native modules. |
MagTag: Add pin A1 as alias for AD1; A1 is preferred
Uh oh!
There was an error while loading. Please reload this page.
Currently, when writing a custom C module, you have to make edits to the
Makefileandmpconfigport.h.This means that, that to distribute a custom C module, you can only do so within the context of a fork of the micropython repository. If I find one person who's written a micropython module for vectormath, and another person who's done a particular communication protocol, then in order to use both of these modules, I have to have a fork of the micropython repository and somehow merge in the code from both of these. There's no easy way to share custom C modules libraries.
I think this contributes hugely to why there are very few custom C modules publicly available for micropython - it's simply too hard to distribute them in a meaningful manner.
Ideally there would be some way of loading compiled libraries (similar to how ctypes allows importing .so files). This is probably impossible in a useful way, but it would be ideal ... allowing drag-drop loading of C modules.
A more realistic way would be to allow some way for code in subdirectories of the ports folder to be able to add their files to the
Makefileandmpconfigport.hfile at compile time.I'm willing to invest some time into solving this problem, but was wondering if there are other solutions I missed, or if someone has a better idea about how to solve it.
The text was updated successfully, but these errors were encountered: