You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The purpose of this is to support a scenario where a single module is half implemented in C and half implemented in Rust (statically linked, resolving circular dependencies at the linker level).
This, while not ideal, is a likely possibility for a codebase which is in the process of migrating from C to Rust. (Note: caveats apply to the execution of cargo test, but a stub can be linked in that case to allow unit tests to run).
In this scenario, the sys bindings are generated correctly, but with a few caveats that need to be corrected:
The #[link(...)] attribute should not be emitted as there is no external library to link with... yet (the linker is linking everything in that precise moment)
The build.rs should not be generated for the same reason
The tests/ directory does no harm, but is superflous at that point
This adds a self_linking configuration key to the sys work mode that would skip the above parts, in order to support the self linking scenario I depicted without having to resort to post modification of the generated code.
I'm not sure if this fits the intended purpose of the gir tool, but I think it can be possibly useful to others.
We use Marco's patch in our project at work. The use case is the one Marco described, we have library we are incrementally porting to rust and we want to bind some of its API since the parts that we are migrating to rust need to call into the C part, however we want to keep generating a single .so/.dll.
This sounds very similar to what I did for windows-rs in microsoft/windows-rs#1863, allowing some Rust code to request extern "system" fn(...) functions that are then provided by some other crate/source, also in Rust 🎉
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The purpose of this is to support a scenario where a single module is half implemented in C and half implemented in Rust (statically linked, resolving circular dependencies at the linker level).
This, while not ideal, is a likely possibility for a codebase which is in the process of migrating from C to Rust. (Note: caveats apply to the execution of
cargo test, but a stub can be linked in that case to allow unit tests to run).In this scenario, the sys bindings are generated correctly, but with a few caveats that need to be corrected:
#[link(...)]attribute should not be emitted as there is no external library to link with... yet (the linker is linking everything in that precise moment)build.rsshould not be generated for the same reasontests/directory does no harm, but is superflous at that pointThis adds a
self_linkingconfiguration key to thesyswork mode that would skip the above parts, in order to support the self linking scenario I depicted without having to resort to post modification of the generated code.I'm not sure if this fits the intended purpose of the gir tool, but I think it can be possibly useful to others.