Shader proc_macro fails to compile if vulkano is nested

[freesig]

So the shader() proc_macro works fine if you use vulkano directly but if you use a crate that has vulkano as a dependency it will not compile if this macro is used.

This is due to the macro creating a mod like this:

mod vs {
  use vulkano
  //etc
}

This use vulkano points to vulkano as an external crate. So it has to be listed directly in your Cargo.toml. We can fix this be changing it to:

mod vs {
  use crate::vulkano
  //etc
}

The putting use vulkano or use my_crate::vulkano in the root of the crate calling this proc_macro (ie. lib.rs). However this will be a breaking change for any projects that are currently using vulkano as a direct dependency and do not have this use in there root.

What are peoples the thoughts on this problem? It would be nice to be able to use this macro without needing to have vulkano as a direct dependency.

[rukai]

I dont understand? https://github.com/rukai/vulkano-text has vulkano as a dependency and it works fine?

[freesig]

This only affects a project that uses the proc_macro directly but doesn't depend on vulkano directly. So if you used vulkano_text as a dependancy but also tried to use the shader macro in your code it wouldn't compile unless you also have vulkano as a dependancy

[rukai]

Ok, I think I see the issue. You want to reexport the vulkano shader macro from nannou, and have users of nannou use it without having vulkano as a dependency. ?

However I don't see how your suggestion allows users to call the macro without including vulkano as a dependency. You cant do use vulkano without vulkano being a dependency?

[freesig]

In that case we'd do use nannou::vulkano. I'm not sure if this is a great solution though. I think the real issue is not having the equivalent of $crate for proc_macro like there is for regular macros.

[Rua]

I think this is the same issue that https://github.com/Lokathor/bytemuck/issues/93 has. So we probably can't fix it, until Rust itself comes with a feature for it.