Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request for Enhancement: Project-level Deku settings #217

Open
v1gnesh opened this issue May 20, 2021 · 9 comments · May be fixed by #229
Open

Request for Enhancement: Project-level Deku settings #217

v1gnesh opened this issue May 20, 2021 · 9 comments · May be fixed by #229

Comments

@v1gnesh
Copy link

v1gnesh commented May 20, 2021

Project-level settings that are set within main.rs can help reduce boilerplate significantly.
Imagine a #[deku(endian = "little")] for each & every struct or enum.
This will make a very noticable difference in readability when working on projects with hundreds of structs and enums.

Over time, project-level settings can be used for future enhancements whenever they come up.

As always, thanks for your time & effort to all the contributors of this very neat project.

@constfold
Copy link
Contributor

Is this possible? I think there is no way to access such file level settings in a procedure macro.

@v1gnesh
Copy link
Author

v1gnesh commented Jun 18, 2021

Any further thoughts on this, @sharksforarms?
Perhaps a .conf file with global settings?

@sharksforarms
Copy link
Owner

Any further thoughts on this, @sharksforarms?
Perhaps a .conf file with global settings?

This would be better suited in another library using deku. For example, another proc-macro crate which annotates struct/enum fields with deku attributes

@v1gnesh
Copy link
Author

v1gnesh commented Jun 19, 2021

Could you show me an example of such a crate/project please?

@wcampbell0x2a
Copy link
Collaborator

Could you show me an example of such a crate/project please?

The following is an example of using deku attributes in another proc-macro library. If that is what you are asking.

https://github.com/wcampbell0x2a/bintex

@sharksforarms
Copy link
Owner

@constfold Any thoughts on #225 (comment) ? Does an attribute named ctx_nested make sense?

@sharksforarms sharksforarms linked a pull request Jun 22, 2021 that will close this issue
@v1gnesh
Copy link
Author

v1gnesh commented Aug 23, 2021

Hi @sharksforarms & @wcampbell0x2a, check these out.
nom's declarative parser seems to be catching up.

nom-derive-impl/src/config.rs
Overriding the default endianness

This will cut my boilerplate noticeably.

@sharksforarms
Copy link
Owner

I'm still not sure how I'd like to approach this, if at all. Have you considered writing your own proc-macro to accomplish this?

I'll try and give you an example when I have time to create one.

@v1gnesh
Copy link
Author

v1gnesh commented Aug 24, 2021

Thank you. As I had mentioned, I'm a noob at programming, barely capable of using this library.
It'll take me a long long time to get comfortable enough to work on proc-macros.

The approach taken by nom-derive seems straightforward (to a user), no?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants