This would certainly need some changes in native_toolchain_rust. I'll do my best to accommodate those. Missing pieces seem to be custom cargo arguments and static library. I'm not sure what the current the state of supporting static libraries in native assets? @dcharkes?

Static linking will not be supported in the foreseeable future, but we are planning on producing a static library to remove unused symbols with the linker in the link hook, which produces the actual dylib being used at runtime.

This would certainly need some changes in native_toolchain_rust. I'll do my best to accommodate those. Missing pieces seem to be custom cargo arguments and static library. I'm not sure what the current the state of supporting static libraries in native assets? @dcharkes?

Yes, the idea is to build static libs in the build hooks and then use the native linker to build a dynamic lib in the link hook. (At some point far in the future we might want to actually have the static lib linked to the AOT snapshot of Dart, but that requires a lot more changes.)

@knopp - just curious, any changes in native_toolchain_rust so far to accomodate this use case? #866 adds even more rust stuff... :)

@mosuem, I published 0.1.0-dev.7 which supports extra cargo arguments. No support for static libraries, but I think I'd wait with that until there is actual support in native assets.

Is there something else required?

Thanks - let me take a look.

No support for static libraries, but I think I'd wait with that until there is actual support in native assets.

#866 will add static libraries. Dart doesn't support static linking, but we will build static libraries in the build hook, and then link them to get a dynamic library in the link hook. This is how we intend to treeshake symbols from the library.

Thanks - let me take a look.

No support for static libraries, but I think I'd wait with that until there is actual support in native assets.

#866 will add static libraries. Dart doesn't support static linking, but we will build static libraries in the build hook, and then link them to get a dynamic library in the link hook. This is how we intend to treeshake symbols from the library.

I don't think native_toolchain_rust can currently be used to do that, without further work. It always adds the asset (dynamic library) to the build output, what you're doing seems to be bit more exotic. Probably not a general use case.

It always adds the asset (dynamic library) to the build output

native_toolchain_c solves that with an optional parameter in the run method. So I think it should be adaptable. But let me take a look, and I might file a PR. I agree that our use case is not super standard.

I see. That should be fairly easy to add. The remaining thing is the assumption that builder is always building a dylib.