Open fenhl opened 9 years ago
@Kingsquee has a setup for compiling and linking dlls at runtime https://github.com/Kingsquee/Worldsong. Perhaps use some of his ideas?
That's GPL.
@Kingsquee beautiful
In all seriousness, while Worldsong has state-preserving runtime loading, It seems to be in contrast to just about every other point of interest:
1) It's an API-less framework that defines the project structure, but otherwise gets out of the way. 2) An eye toward flexible compilation: Should the whole project be a collection of libraries, or compiled into a single executable? Should plugins be treated as dylibs, rlibs, or (soon™)modules? Should we run LTO or not?
If it is compiled as a collection of libraries, it should:
3) Be very easy for anyone who understands the basics of programming to modify/mangle/hilariously mutilate the end application. 4) Support (eventually automated) addition / removal of packages of functionality without sacrificing mod flexibility. This comes at the cost of an author occasionally needing to manually add process-order metadata to a package to avoid conflicts with others executing at the exact same location in a schedule, or (at worst) the person installing the mod to push its process call(s) up or down in a schedule themselves.
In context of the last two goals, perhaps now the GPL makes a bit more sense. In my target use-case, throwing un-diffable third-party source-less version-locked DLLs around isn't beneficial for a modding community.
So I'm not sure how much inspiration it can be!
Without knowing much about how dylibs/rlibs work, my approach to compilation would be moving all the plugins into a submodule and running codegen for by-name and iterator access, then letting Cargo compile the whole thing.
The purpose of this project is to enable Rust binaries to support the addition of plugins. There are three perspectives to be considered here:
This project should cover all three. So how do we structure it to provide this functionality?