Adds re-exporting macros and crate renaming support;

[dman-os]

The scenario:

I want to pull all my dependencies through a deps crate in my workspace and dynamic link to this deps crate to speed up compilation allowing one fast iteration times.

Look at the strategy deployed by bevy for an example.

The challenge:

Proc macro's stop working as they expect to find some of the crates they depend on to be imported in the current crate.

The bytemuck_derive crate works with types from bytemuck using snippets as the one given below...

    quote!(::bytemuck::Pod)

...which fails to find the bytemuck crate as it's located in crate::deps::bytemuck.

Similar issues elsewhere: serde, yew

The solution:

If unable to find bytemuck crate in the manifest of the crate using the macro (detection using proc-macro-crate), use self::bytemuck qualifier. Anyone who intends to use re-exporting can then import bytemuck::self locally.

use deps::bytemuck{self, Zeroable, Pod};

#[repr(C)]
#[derive(Clone, Copy, Zeroable, Pod)]
struct Vertex{
    pos: [u32; 4],
}

We avoid breaking changes by using the old ::bytemuck qualifier if bytemuck is found in the manifest.

Courtesy of proc-macro-crate, we're also able to handle if bytemuck is found in the manifest but under a different name.

Includes:

• adds bytemuck_derive into a workspace rooted in bytemuck

[danielhenrymantilla]

Changes are sensible 👍 but for two things (c.f. the attached comments):

• The proc-macro-crate dependency should be feature-gated (I'll let @Lokathor judge whether that should be an enabled-by-default feature or not; I think it's better for it not to be enabled by default), since it may break builds for #![no_std] dependencies;

• Using self::bytemuck in the no-explicit-and-direct-bytemuck-dependency case seems unnecessarily restrictive: using bytemuck can be just as useful, with the added benefit that if bytemuck happens to be an extern crate, then users won't need to write use ::bytemuck /* ::{self} */;

[dman-os]

@danielhenrymantilla good suggestions. They've been applied.

[Lokathor]

You know that generic functions are code-generated in the crate that uses them, right? So if you use any generic things, including all of bytemuck, they'll still get put into your own crate and code generated there.

[dman-os]

@Lokathor okaayy. Sorry, I'm new to rust and...what exactly does that change?

[Lokathor]

Basically I'm very skeptical that this "deps crate" build style will help your usage of generic functions. When you build the deps crate the dylib literally does not contain actual code for generic functions. Generics are monomorphized in the crate that uses them, so generic code is only actually generated when building a crate that uses the generic function. You can't just re-export bytemuck::cast in a project_deps crate to get the cast function to build into the dylib and cheaply link to that.

I'm sure you get some build time benefit overall, but bytemuck specifically, being 99% generic and heavily inlined, wouldn't see any gains.

[Lokathor]

Which is not to say that we can't merge the PR (I'll try to look closely at it Sun/Mon), but you should be aware that this might add up to "no difference at all"

[dman-os]

build style will help your usage of generic functions
being 99% generic
Generics are monomorphized in the crate that uses them

OHh. Okay. Damn. I see why rustaceans avoid generics like the plague. I'm guessing they don't benefit from any incremental compilations.

Anyways, I guess I could choose and bring in some dependencies into the main crate. Having them all in one crate would be nice but I'm playing with a toy project and I could just work off my fork.

Thanks for your time.

[Lokathor]

They do get some incremental support, but they're not a "build and never touch it again" sort of situation like you get with C libs.

[Lokathor]

Since this PR can't even really accomplish the initial goal (less rebuild times), and since I'm not usually a workspace user and I'd have to learn about them if one was added to this project, I'm gonna close the PR.

[blueforesticarus]

I think the primary utility of this is the ability to reexport proc macros in a "common" crate, which usefull in a workspace repos where the alternative is to copy the dependency to 20 Cargo.tomls