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

Move border! macro here #35

Open
EdJoPaTo opened this issue May 8, 2024 · 7 comments
Open

Move border! macro here #35

EdJoPaTo opened this issue May 8, 2024 · 7 comments

Comments

@EdJoPaTo
Copy link
Contributor

EdJoPaTo commented May 8, 2024

ratatui has a border! macro behind the macro feature flag. Move this macro here and remove that feature flag from ratatui.

@kdheepak
Copy link
Collaborator

kdheepak commented May 8, 2024

I was hoping this crate would be a playground or testing ground for ideas for macros (especially if we want to write proc macros in the future), and if an idea seems interesting we could bring it to core. I suspect most people don't add an additional crate just for a macro.

Is there a reason you want to bring the border! macro here? imo, if it is a declarative macro, the burden of maintaining it in the ratatui crate is low.

@kdheepak
Copy link
Collaborator

kdheepak commented May 8, 2024

Alternatively, we can bring the border! macro here, add this as a dependency to the ratatui crate and re-export it.

@EdJoPaTo
Copy link
Contributor Author

EdJoPaTo commented May 8, 2024

There should be a single place for them. playground and upstream would be also fine.

Compiling ratatui takes ages and splitting it up is likely a good idea. Not entirely sure about it but somehow my memory associates providing macros with added compile time on the crate that provides them. But that might only be the case for proc macros?

@kdheepak
Copy link
Collaborator

kdheepak commented May 8, 2024

My understanding is that the extra compile time for ratatui would happen in two cases:

  1. If any dependency of ratatui uses proc_macros2 or syn as dependencies: https://reddit.com/r/rust/comments/19dkoj7/psa_prefer_declarative_macros_to_improve_compile/kj6gsdq/
  2. If we use the macro in ratatui

I thought users that don't use the macro shouldn't see a difference in compile time, even if it wasn't behind a feature flag.

@EdJoPaTo
Copy link
Contributor Author

EdJoPaTo commented May 8, 2024

I think there is a mix-up of compile time for a specific crate and total compile time. Once a crate is compiled it's not needed to compile again. The linking process is still needed tho.

Everything that is published from a crate (with the given feature flags) will take time to compile the crate and will take time on linking.

Moving stuff from one crate to a dependency crate results in parallel compilation.

ratatui can only be compiled once all its dependencies are compiled but all the dependencies can be compiled in parallel. Meaning: moving something from ratatui to a dependency of ratatui will speed up the compilation of ratatui and the dependency can be compiled in parallel to other stuff.

When ratatui would move stuff like buffer, widgets, … to their own crates it would speed up compilation as these parts can be built in parallel then. (Widgets require buffer, so there are some sequences.)
On the other side, monorepos also annoy me, so sticking with separate repos and clear versions on what is possible to split up is what I prefer personally. Like having unicode-truncate in its own repo and use its functionality rather than building everything in the single ratatui repo.

The mentioned syn for example only needs to be compiled once for multiple crates using it, but all the crates using it will compile slowly as proc macros are hard to compile. Crates depending on proc macro crates can compile way faster as they only need what was published from the dependencies.

So… tldr: I assume keeping it a dependency and reexport stuff in the main crate should result in faster compile times both for users of ratatui and for contributions to ratatui.

@kdheepak
Copy link
Collaborator

kdheepak commented May 8, 2024

Thanks for explaining! That makes sense. I didn't know about some of the nuances here.

We should bring this up as a part of a broader discussion with the team to discuss the organization / user experience / compilation time tradeoffs etc.

@EdJoPaTo
Copy link
Contributor Author

EdJoPaTo commented May 8, 2024

Also… I suspect the use of generics in ratatui is one of the major factors for compile time (compiling ratatui, the crates using these generics and not sure how much that affects linking directly or just by that many functions generated by these generics)

Lists the generic functions: rg --glob '*.rs' 'fn \S+<'

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

No branches or pull requests

2 participants