mbaulch / rustifact Goto Github PK

I don't currently have a use for write_enum!, but can imagine circumstances in which it may be useful.

If anyone has a need for write_enum! then please reply to this issue and let me know.

The obvious approach to testing provided by cargo isn't suitable when build scripts are involved. Investigate alternative approaches, and implement one.

NOTE: A related issue is the testing of examples in the documentation. Consider whether a unified approach could be beneficial.

Currently, we assume that the types for identifiers imported via use_symbols! are manually brought into scope. These type identifiers are created in the corresponding implementation of ToTokenStream.

We can't just blindly use absolute paths, as there are contexts where the prefix crate:: is required. To utilise absolute paths, we'd need to selectively transform this path in use_symbols!: presumably with a proc macro.

Presumably in a separate rustifact_derive crate. If there are obvious use cases this doesn't cover, perhaps add an example of implementing ToTokenStream.

Currently, output created in the build script (via the write_X! family of macros) is simply written to OUT_DIR and left as is. In the case that a call write_X exporting a symbol FOO is removed, the call use_symbols!(FOO) will still succeed until OUT_DIR is replaced: typically by calling cargo clean, though also by changing release modes.

It seems desirable that Rustifact entries in OUT_DIR should be cleaned, or old entries should be somehow dereferenced, so that referencing issues aren't hidden until the next complete rebuild. No matter how this is tackled, there are a number of tradeoffs involved.

TODO: Explore these tradeoffs and implement the best strategy. Otherwise, keep the status quo, document it, and explain why this is the preferred approach.