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
{{ message }}
This repository has been archived by the owner on Jul 3, 2020. It is now read-only.
There is a proposed solution at the bottom of the issue. The following sections are included for discussion and documentation purposes.
Things that don't work.
Nested module with path attribute
For most uses of include!, this can be worked around by declaring an inner module and use the path attribute such at:
#[path="../real/main.rs"]
mod inner;
However, this solution is not feasible for our use case because:
main is private and cannot be called
Produces an error because macro_use is no longer at the crate root.
Furthermore, although no_std will compile, it will produce a warning since it is not at the crate level.
Embed main.rs into lib.rs
Simply moving the contents of the root module such as main.rs into lib.rs does not work. Since lib.rs is in a separate directory, it is unable to find any additional modules.
Hacky Solution
Read the main.rs and embed it in the generated lib.rs
Extract troublesome statements like inner attributes and macro_use and move them to top level.
Add pub to main.
Add path attribute so that child modules will be resolved.
Example:
// Inner attributes
#![no_std]
#![cfg_attr(
not(any(
feature = "example_feature"
)),
allow(dead_code, unused_extern_crates, unused_imports)
)]
// macro_use attribute is only allowed at the crate root.
#[macro_use]
extern crate lazy_static;
#[path="../real/"]
mod example {
mod child_mod;
// pub added to main
pub fn main() {
child_mod::do_something();
}
}
use example::*;
Proposed Solution - Create temporary file in user's source directory.
This solution is one I avoided experimenting with because it requires producing files outside of the target folder. However, it is the simplest. Because of is simplicity, it should be less fragile. I believe this solution should be implemented unless another one is proposed.
Read root module such as main.rs
Write it along with the current contents of cargo-apk's lib.rs to a temporary file in the same folder as main.rs.
Compile it.
Does anyone have thoughts about a better way to handle this case? @mb64
The text was updated successfully, but these errors were encountered:
My understanding of how it used to work is that it would tell rustc to build an executable, then intercept the linker call and link a dynamic library instead (and link in all the extra stuff, such as android_native_app_glue). This worked, but with an ugly linker wrapper.
With #223, it makes a new file lib.rs (roughly replacing glue_obj.rs) that looks like
include!("/path/to/src/main.rs");// Side note: I'm pleasantly surprised this resolves modules correctly#[no_mangle]pubextern"C"fnandroid_main(...){/* stuff with main() */}
and it tells rustc to compile this as a static library.
It would be possible to go back to intercepting linker calls. There might be a nicer way to do it than a wrapper executable; I'm not familiar with the Cargo library.
Aside from copying the whole source directory (which might be bad if things include!("../../file_outside_of_source_dir")), I think a temporary file in the source directory might be the best solution. As long as it gets deleted afterward, and it doesn't conflict with other files in the source directory, it won't have a real impact on users.
The Problem
The build system merged in #223 fails to build crates which have inner attributes in the root module.
Incomplete Example
References
There is a proposed solution at the bottom of the issue. The following sections are included for discussion and documentation purposes.
Things that don't work.
Nested module with path attribute
For most uses of
include!
, this can be worked around by declaring an inner module and use the path attribute such at:However, this solution is not feasible for our use case because:
macro_use
is no longer at the crate root.no_std
will compile, it will produce a warning since it is not at the crate level.Embed main.rs into
lib.rs
Simply moving the contents of the root module such as
main.rs
intolib.rs
does not work. Sincelib.rs
is in a separate directory, it is unable to find any additional modules.Hacky Solution
main.rs
and embed it in the generatedlib.rs
macro_use
and move them to top level.pub
tomain
.path
attribute so that child modules will be resolved.Example:
Proposed Solution - Create temporary file in user's source directory.
This solution is one I avoided experimenting with because it requires producing files outside of the
target
folder. However, it is the simplest. Because of is simplicity, it should be less fragile. I believe this solution should be implemented unless another one is proposed.main.rs
lib.rs
to a temporary file in the same folder asmain.rs
.Does anyone have thoughts about a better way to handle this case?
@mb64
The text was updated successfully, but these errors were encountered: