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

Include module path in virtual file names #11852

Merged
merged 5 commits into from
Jan 21, 2025

Conversation

kLabz
Copy link
Contributor

@kLabz kLabz commented Dec 4, 2024

When using -D dump-dependencies, macro modules show up with their file names, but for macro generated modules that's unusable (they're all named /server/file_x_y which doesn't help much).

tbh I'm not sure this is the kind of fix we need here, but I also didn't want to break things relying on current -D dump-dependencies output.

src/typing/macroContext.ml Outdated Show resolved Hide resolved
@Simn
Copy link
Member

Simn commented Dec 5, 2024

We could name these something like defineType/Module_step_counter to make it a bit more human-readable. Where does that /server/ you mention come from?

@Antriel
Copy link
Contributor

Antriel commented Dec 5, 2024

The /server/ was from my example. It just includes the full path, and that happened to be the project root. Ideally it would include the package and the module name, but even just the module name is better than nondescript name.

@Simn
Copy link
Member

Simn commented Dec 5, 2024

Yes the package should be there too of course. Internally the naming doesn't really matter, the only part that's important is that the file key is unique. So a normal module path with the step and counter suffix would be fine too.

@kLabz
Copy link
Contributor Author

kLabz commented Dec 5, 2024

Printf.sprintf "%s_%i_%i" (s_type_path mpath) step !virtual_counter should do?
Would also be nice to convert that dotpath to directory structure, I suppose

@skial skial mentioned this pull request Dec 9, 2024
1 task
@Antriel
Copy link
Contributor

Antriel commented Dec 17, 2024

RE dotpath to directory structure: Yes please. It will be nicer. I could replace dots with slashes on my dependency visualizer, but that would require special handling for .macro.hx and such, which is less nice.

@kLabz kLabz force-pushed the generate_virtual_with_mpath branch from 1445c19 to df5a27e Compare January 21, 2025 07:27
@kLabz
Copy link
Contributor Author

kLabz commented Jan 21, 2025

@Antriel when you have some free time, can you check if that new path works for you?

@Antriel
Copy link
Contributor

Antriel commented Jan 21, 2025

Seems to work well, except for modules defined without any package, which end up without the project directory. The difference in those is that the last one has pack: ['reactor'] as part of the type definition.

- C:\Users\peter\Dropbox\work\NextRealm\games\SnowFight\client\file_1_30
- C:\Users\peter\Dropbox\work\NextRealm\games\SnowFight\client\file_1_33
- C:\Users\peter\Dropbox\work\NextRealm\games\SnowFight\client\file_1_76
- C:\Users\peter\Dropbox\work\NextRealm\games\SnowFight\client\file_1_77
+ C:\SerApiUiApi0_1_30
+ C:\SerApiSelfLogicApi0_1_33
+ C:\SerApiManagerClientApi0_1_76
+ C:\Users\peter\Dropbox\work\NextRealm\games\SnowFight\client\reactor\SenderSerApiManagerClientApi00_1_77

@kLabz
Copy link
Contributor Author

kLabz commented Jan 21, 2025

Hmm. I suppose I should handle pack = [] case and use "." there
Thanks!

@kLabz kLabz force-pushed the generate_virtual_with_mpath branch from df5a27e to b908b5e Compare January 21, 2025 08:37
@kLabz kLabz marked this pull request as ready for review January 21, 2025 08:38
@Antriel
Copy link
Contributor

Antriel commented Jan 21, 2025

Yep, that fixed it.

@kLabz kLabz merged commit d5dd8f5 into HaxeFoundation:development Jan 21, 2025
58 of 61 checks passed
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 this pull request may close these issues.

3 participants