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
Right now, the cxx crate contains both runtime components (e.g. cxx::unique_ptr) and build time components (e.g. cxx::gen, cxx::Build).
This is negative because:
For cross compilation builds, this requires that what should be build-only dependencies be supported on the target.
This builds more functionality into the target binary than needed. If cxx is linked statically, there's a good chance most of this will be removed, but it will bloat in cases where it's linked dynamically.
For homogenous build systems (bazel, buck, etc.) this requires them to pull in the cc and link_cplusplus crates to their source tree, which will never actually be used.
The two ways I see forwards here are:
Split it using features. Users of homogenous build system, or who cared about binary size, etc. would be expected to disable a default feature to get a support-code-only version of the crate.
Split it into separate crates, e.g. cxx-support and cxx-build, possibly keeping the main cxx crate as a wrapper that re-exports both.
Opinions?
The text was updated successfully, but these errors were encountered:
I will take care of this one since I'll probably be picky about the directory layout. It sounds like you have a workaround for now? If so, I'll aim to get this done and published early next week.
Right now, the cxx crate contains both runtime components (e.g.
cxx::unique_ptr
) and build time components (e.g.cxx::gen
,cxx::Build
).This is negative because:
cc
andlink_cplusplus
crates to their source tree, which will never actually be used.The two ways I see forwards here are:
Opinions?
The text was updated successfully, but these errors were encountered: