Support the associated proc macro pattern #291
Conversation
There was a problem hiding this comment.
Looks great! Can we leave a suggestion in the crate doc comment to suggest that this is an option? We'll also want to maybe open an issue to track making this a more strongly-worded suggestion once this technique has baked in the ecosystem and folks agree it's the way to go.
jswrenn
force-pushed
the
assoc-proc-macro-pattern
branch
from
272abc7
to
2ec7bab
Compare
README.md
Outdated
| crate. These derives are re-exported from `zerocopy`, so it is not | ||
| necessary to depend on `zerocopy-derive` directly. | ||
|
|
||
| However, you may experience better compile times if you explicitly depend |
There was a problem hiding this comment.
Maybe "...if you don't use the derive feature and instead explicitly depend..." to make it clear that this is instead of the feature, not in addition to it?
Also, maybe s/explicitly/directly/?
There was a problem hiding this comment.
Good point. I opted for slightly more concise wording, but the effect should be the same.
There was a problem hiding this comment.
Doesn't look like these changes actually got pushed?
There was a problem hiding this comment.
Sigh. I totally typed them in README.md instead of lib.rs, and then gleefully overwrote README.md with generate-readme.sh.
|
Oh and one other thing: could you also bump the version numbers to 0.7.1 in this PR? I'll release that once this merges so folks can take advantage of it. |
jswrenn
force-pushed
the
assoc-proc-macro-pattern
branch
from
2ec7bab
to
ee7afd5
Compare
Mostly. Unfortunately,
Done. |
jswrenn
force-pushed
the
assoc-proc-macro-pattern
branch
2 times, most recently
from
07f5ea0
to
0e2f636
Compare
The "associated proc macro pattern" is a trick for ensuring that
`zerocopy` and `zerocopy-derive` have equal verions, even when
the optional `derive` feature of `zerocopy` isn't used.
The `derive` feature of `zerocopy` provides a convenient way for
end-users to depend on `zerocopy-derive` that ensures that `zerocopy`
and `zerocopy-derive` have exactly equal versions. Unfortunately,
using this feature creates a dependency between these two crates that
prevents them from being built in parallel. A compile-time-conscious
user of `zerocopy` can avoid this by depending on both of these crates
explicitly, but this places the onus on them to ensure that their
versions are exactly equal.
The "associated proc macro pattern" is a trick for ensuring that
`zerocopy` and `zerocopy-derive` have equal verions, even when
the optional `derive` feature of `zerocopy` isn't used. With it,
an end-user of zerocopy can write:
[dependencies]
zerocopy = "MAJOR.MINOR"
zerocopy-derive = "MAJOR.MINOR"
...and cargo will ensure that the actual versions that are used
are exactly equal.
For more information, see: https://github.com/matklad/macro-dep-test
jswrenn
force-pushed
the
assoc-proc-macro-pattern
branch
from
0e2f636
to
e949345
Compare
The "associated proc macro pattern" is a trick for ensuring that
zerocopyandzerocopy-derivehave equal verions, even when the optionalderivefeature ofzerocopyisn't used.The
derivefeature ofzerocopyprovides a convenient way for end-users to depend onzerocopy-derivethat ensures thatzerocopyandzerocopy-derivehave exactly equal versions. Unfortunately, using this feature creates a dependency between these two crates that prevents them from being built in parallel. A compile-time-conscious user ofzerocopycan avoid this by depending on both of these crates explicitly, but this places the onus on them to ensure that their versions are exactly equal.The "associated proc macro pattern" is a trick for ensuring that
zerocopyandzerocopy-derivehave equal verions, even when the optionalderivefeature ofzerocopyisn't used. With it, an end-user of zerocopy can write:...and cargo will ensure that the actual versions that are used are exactly equal.
For more information, see: https://github.com/matklad/macro-dep-test