Mostly a thought for the future, but does Oxide have any need or interest in cross-compilation support for usdt?

The current attribute macro method uses cfg's to select the correct probe generator to use, but those cfg's are forced to happen during the macro crate's compilation which is always compiled on the host. In a cross-compilation scenario this means that the wrong probe generator is chosen and errors ensue (if one is lucky).

A fundamental requirement for cross-compilation would be that the usdt-impl couldn't be chosen based on cfg's; all platforms would need to be capable of producing the usdt-impls of other platforms. This isn't much of a technical problem, I believe, but definitely a code organisational problem.

Some possible ways to achieve cross-compilation would be:

• Simply always emit all probe variants in target-specific cfg!() blocks. Simple, but possibly not great for build times or for debugging the macro expansion: 10 probes would today already expand to around 5000 lines of code.
• Emit target-specific cfg!() blocks containing the original (or equivalent) mod provider { ...fns... } blocks with parametrised attribute macros on them, #[usdt::provider(linux, x86_64)] style, and use these parameters to choose the actual implementation.
• Possibly some kind of environment variable shenanigans to parametrise the macro build?
• Explicitly disable cross-compilation by detecting it (somehow?) and using the empty impl in those cases.

(As you may guess, it turns out my downstream users were doing cross-compilation and my taking up USDTs has thus caused them some consternation, which is why I'm pondering about this :) )