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
I think build.rs and procedural macros should be able to take advantage of std-aware cargo too. This is needed to get rid of the sysroot as a concept entirely. This is also needed to boostrap a working rust from a plain compiler without any libraries. This type of boostrapping is very advantageous of distros.
The text was updated successfully, but these errors were encountered:
I was poking around at trying to get a proc-macro to compile, dynamically link to, and call a inline-proc-macro (i.e. what this crate used to do). This is difficult right now because proc-macro (the crate) is statically linked and has important thread locals, but if I compile it by hand I can compile it to a dylib and share those with my inline-proc-macro, at which point things work.
This is absurdly niche and wouldn't even be stable behavior even if it worked, but it's sort of a use case that would be enabled by letting me say something like cargo build --build-std-host=proc-macro -Z target-applies-to-host -Z host-config --config host.rustflags="--crate-type=dylib -C prefer-dynamic".
I'm honestly not sure if this is an argument for or against this feature.
I think build.rs and procedural macros should be able to take advantage of std-aware cargo too. This is needed to get rid of the sysroot as a concept entirely. This is also needed to boostrap a working rust from a plain compiler without any libraries. This type of boostrapping is very advantageous of distros.
The text was updated successfully, but these errors were encountered: